fix(dips): create indexing rule before acceptIndexingAgreement

[MoonBoi9001]

Motivation

The indexer-agent runs two concurrent loops for DIPs. One accepts proposals on-chain every 5 seconds. The other runs the wider reconciliation every 15 seconds and is responsible for upserting the dips indexing rule that tells graph-node to deploy the subgraph.

Both loops read from the same pending_rca_proposals table. The accept loop removes a proposal from that table as soon as acceptIndexingAgreement confirms on-chain. The reconcile loop only creates the rule if the proposal is still pending when its tick fires.

On Arbitrum, acceptIndexingAgreement typically confirms in a second or two, so the accept loop clears the row long before the next 15s reconcile tick. The rule is never created. Graph-node never receives the deploy instruction. Subsequent reconciliation then sees a DIPs allocation with no matching rule and tries to unallocate it with reason: "group:none" — which fails with IE067, leaving the agent to loop on the same failed action while the indexer silently collects nothing.

The behaviour is timing-dependent on hardhat, where receipts take 4-8s and the reconcile tick occasionally wins. It becomes deterministic on Arbitrum, where receipts land in ~1s and the reconcile always loses. The existing legacy path does not help: it reads IndexingAgreement, a table populated only by the deprecated voucher system, not the RCA flow.

Summary

• Extract the per-proposal rule logic into ensureDipsRuleForProposal and call it eagerly from processProposal, before acceptIndexingAgreement broadcasts.
• The reconciliation loop continues to call the same helper, now as defense-in-depth.
• Three unit tests cover the new ordering, the blocklist short-circuit, and the case where a matching rule already exists.

Stack

Targets feat/dips-on-chain-cancel (#1190) rather than main-dips so the author of the open stack (#1181, #1185, #1190) does not have to rebase. The bug landed with feat/dips-support (#1172, merged) and is inherited by every branch below #1178. Landing here lets #1178 rebase onto this fix and pull it in with no further coordination.

[MoonBoi9001]

Wrong base — the race this fixes only exists on fix/getrewards-subgraph-service (#1178), which introduces the dedicated 5s startProposalAcceptanceLoop in commit ad6035a. Every branch below #1178 (main-dips, #1181, #1185, #1190) runs acceptPendingProposals from the main reconciliation tick alongside ensureAgreementRules, so the receipt cannot clear the pending row before rule creation. Folding this fix into #1178 directly.