feat: accept agreement proposals from senders with escrow

[MoonBoi9001]

TL;DR

Today the indexer only accepts indexing-agreement proposals whose sender holds an on-chain manager role; everyone else is turned away. This adds a fallback that admits a sender when the account behind its signature already holds enough escrow (default 1 GRT) in the query-fee escrow the service watches. The role path is unchanged — this only widens who is allowed to propose.

Motivation

When an indexer receives an indexing-agreement proposal, it recovers who signed it and checks that signer against the set of accounts granted the on-chain agreement-manager role. That gate is right for the managed flow, but it shuts out a legitimate, already-funded payer who was never granted the role. Without an alternative, those proposals are rejected before any pricing or manifest checks run, and the only way to onboard such a payer is to hand out the manager role.

This adds a second, permissionless route: if the recovered signer resolves to an account holding escrow at or above a configured floor, the proposal proceeds to the normal pricing and manifest checks. The balance consulted is the query-fee (TAP) escrow the indexer already watches — so it is evidence the sender is a real, funded participant, not a guarantee the recurring agreement itself will be paid — and the role check still runs first, leaving managed senders unaffected.

Summary

• Admit a sender the role gate rejects when its recovered signer holds escrow at or above a minimum.
• Check escrow against the recovered signer, never the proposal's caller-supplied payer field.
• Reuse the query-fee (TAP) escrow snapshot the service already watches; no extra subgraph query.
• Treat that balance as an admission signal the sender is funded, not proof the agreement is paid.
• Add a configurable minimum balance (default 1 GRT), with a TODO to later derive it from price.
• Treat an empty escrow snapshot as transient so a funded sender is not rejected during an outage.
• Reject an underfunded or unknown sender with a dedicated insufficient-escrow reason.

[RembrandtK]

Are query-fee and indexing-payment escrows being conflated here? I might be missing something, but it looks like the snapshot we're reading is scoped to the query-fee collector (receipts_verifier_address_v2), whereas DIPs agreements settle through the RecurringCollector. Escrow is keyed on (payer, collector, receiver), so a balance on the query-fee escrow tells us nothing abouth the Recurring Collector one?

I'm also concerned about the flat 1 GRT floor. The meaningful threshold should be based on possible future claim(s) rather than a fixed amount?

Do we even need this now? We agreed not to require this for Recurring Agreement Manager, which is the only immediate use case?

[MoonBoi9001]

I'm also concerned about the flat 1 GRT floor. The meaningful threshold should be based on possible future claim(s) rather than a fixed amount?

I was planning to defer that to a follow up, but just get the ball rolling in this PR with a 1 GRT floor.

Do we even need this now? We agreed not to require this for Recurring Agreement Manager, which is the only immediate use case?

We can close for now, I think this was a reasonable base to build out a more permissionless system from, and a natural extension of the PR sequence from #1045 > #1048 > #1049, but agreed that it's not strictly necessary atm.

Are query-fee and indexing-payment escrows being conflated here? I might be missing something, but it looks like the snapshot we're reading is scoped to the query-fee collector (receipts_verifier_address_v2), whereas DIPs agreements settle through the RecurringCollector. Escrow is keyed on (payer, collector, receiver), so a balance on the query-fee escrow tells us nothing abouth the Recurring Collector one?

Yes this needs addressing when reopened/revisited, nice catch.

[MoonBoi9001]

Reopened as draft, pending refactor, so this doesnt get lost in the noise