fix(chain): tolerate recovered RPC minority during CG binding

[branarakic]

Stack dependency

This PR is stacked on #2184 because testnet-canary does not yet contain the finalized Context Graph name-hash resolver.

After #2184 merges, retarget this PR to testnet-canary before merging. Do not merge the stacked PR independently of #2184.

User impact

Cold VM / Context Graph name-hash resolution no longer restarts the complete O(slots × providers) refresh merely because a minority of public RPC backends times out, disconnects, or returns HTTP 429.

The 2-of-3 rule applies only to per-slot reads. A positive/null resolution and index/cache commit still require every configured backend to answer the final registry high-water fence; persistent minority unavailability remains retryable and fails closed.

For a three-provider configuration, two agreeing covering providers may stage slot work while the third has a retryable transport failure. The refresh does not return a positive/null resolution or commit its index/cache until final high-water verification confirms the complete provider boundary. If the third provider remains unavailable at that boundary, the refresh fails closed and stays retryable. Safety remains fail-closed:

• a strict majority of the captured covering provider set must fulfill the slot read;
• every fulfilled provider must return the same value;
• deterministic contract-view failures such as ethers BAD_DATA are non-retryable;
• non-retryable failures, disagreement, or loss of quorum abort the refresh;
• known lagging providers remain excluded for slots they cannot cover;
• providers with a retryable high-water failure remain in the quorum denominator as potentially covering, preventing an unsafe three-to-one provider collapse;
• the existing anchor, scope, abort, and all-or-nothing index/cache commit fences remain intact.

Before

sequenceDiagram
    participant Agent as DKG Agent
    participant RPC1 as RPC A
    participant RPC2 as RPC B
    participant RPC3 as RPC C
    Agent->>RPC1: Read registry high-water and slot
    Agent->>RPC2: Read registry high-water and slot
    Agent->>RPC3: Read registry high-water and slot
    RPC1-->>Agent: Matching value
    RPC2-->>Agent: Matching value
    RPC3--xAgent: Timeout or HTTP 429
    Agent-->>Agent: Abort the complete refresh

Loading

After

sequenceDiagram
    participant Agent as DKG Agent
    participant RPC1 as RPC A
    participant RPC2 as RPC B
    participant RPC3 as RPC C
    Agent->>RPC1: Read registry high-water and slot
    Agent->>RPC2: Read registry high-water and slot
    Agent->>RPC3: Read registry high-water and slot
    RPC1-->>Agent: Matching slot value
    RPC2-->>Agent: Matching slot value
    RPC3--xAgent: Retryable slot timeout or HTTP 429
    Agent->>Agent: Stage the strict-majority slot result
    Agent->>RPC1: Verify final registry high-water
    Agent->>RPC2: Verify final registry high-water
    Agent->>RPC3: Verify final registry high-water
    alt Every configured backend answers consistently
        RPC1-->>Agent: Final high-water
        RPC2-->>Agent: Final high-water
        RPC3-->>Agent: Final high-water
        Agent-->>Agent: Commit the fully fenced refresh
    else Any backend remains unavailable or disagrees
        RPC3--xAgent: Unavailable or inconsistent
        Agent-->>Agent: Fail closed without index/cache commit
    end

Loading

Validation

• pnpm --filter @origintrail-official/dkg-chain build
• focused resolver/fence tests: 3 files, 56 passed, 0 failed
• full chain unit lane: 49 files, 950 passed, 1 skipped, 0 failed
• git diff --check