feat: track on-chain RCA offers for dipper idempotency gate

[MoonBoi9001]

Motivation

The indexing-payments-subgraph tracks the IndexingAgreement lifecycle from the point an indexer calls acceptIndexingAgreement on-chain -- the AgreementAccepted event creates the stateful entity and subsequent AgreementUpdated / AgreementCanceled / RCACollected events mutate it. What the subgraph does not currently index is the earlier pre-accept step where dipper calls RecurringCollector.offer() to post the RCA offer that indexers will later accept.

Dipper needs to know whether an offer for a given agreement already exists on-chain before submitting a new one. Without that check, a dipper crash between broadcasting offer() and persisting the result locally would cause the restart to resubmit, wasting gas on an already-successful on-chain transaction.

Summary

• Adds a handleOfferStored mapping on the RecurringCollector data source that creates an Offer entity keyed by agreementId (bytes16) when the contract emits OfferStored.
• Declares Offer immutable. Duplicate OfferStored events for the same agreementId are guaranteed by the contract's id derivation to carry the same offerHash, so the handler returns early on the second event rather than attempting an immutable rewrite (which would halt the subgraph).
• Adds the OfferStored event to abis/RecurringCollector.json and binds it in subgraph.template.yaml.
• Matchstick coverage for the handler: first-wins entity creation and duplicate-event no-op.

Generated with Claude Code

[Maikol]

I don't think this is exactly as described here. We are using the agreementId as unique key but OfferStored could be emitted multiple times for the same agreement id. If an offer is created and updated we would be skipping the update event:

if ($.rcauOffers[rcau.agreementId].offerHash != rcauHash) {
    $.rcauOffers[rcau.agreementId] = StoredOffer({ offerHash: rcauHash, data: abi.encode(rcau) });
    emit OfferStored(rcau.agreementId, agreement.payer, OFFER_TYPE_UPDATE, rcauHash);
}

To keep immutable entities we would have to use the offerHash as an id but then from the dipper we would need to find the latest valid offer. I would suggest we drop immutability and overwrite the Offer with the latest terms, that way from dipper we query by agreement id and use the latest values.