fix: reduce post-reallocation receipt rejection window during network subgraph polling gap

[cargopete]

Context

This PR addresses a partial contributor to the post-reallocation query outage reported by Ellipfra and others. The full outage lasts around 60 minutes and is primarily caused by gateway-side network subgraph lag - the gateway continues issuing receipts with stale allocation IDs for the duration of its own propagation delay, which is not addressable from indexer-rs, unfortunately.

However, there is a shorter initial window (~0–5 minutes) where indexer-service itself contributes errors due to two gaps in how recently-closed allocations are handled at the service layer. This PR attempts to fix those two gaps.

What indexer-service-rs is doing wrong

Indexers logs show:

Receipt allocation ID `0xblahblah...` is not eligible for this indexer

This error fires in the minutes immediately following a reallocation, then disappears - while gateway errors persist for the full 60 minutes. The indexer-service errors are caused by two issues:

Issue 1 — Attestation signer evicted too eagerly (crates/monitor/src/attestation.rs)

modify_signers unconditionally drops any signer not present in the current allocations map:

signers.retain(|id, _| allocations.contains_key(id));

Between the on-chain closure and the monitor's next successful poll, the signer is gone. If a receipt arrives during this window, the query is served but attestation_middleware returns attestation: null, producing BadResponse(bad attestation: ...) at the gateway.

Issue 2 — Receipt eligibility hard-rejects with no grace period (crates/service/src/tap/checks/allocation_eligible.rs)

AllocationEligible::check does a hard lookup against the same watch channel. If the allocation is transiently absent during the polling gap, the receipt is immediately rejected - no query is processed, no attestation is returned.

The existing recently_closed_allocation_buffer_secs config (default: 3600s) was designed to prevent exactly this, but it is only applied to the network subgraph query. It is never threaded to the signer eviction logic or the eligibility check at the service layer.

Fix

Fix 1 adds an evicted_at: HashMap<Address, Instant> tombstone map to modify_signers. Signers are kept alive for grace_period after first eviction rather than being dropped immediately.

Fix 2 adds a recently_seen: HashMap<Address, Instant> local cache to AllocationEligible. Before hard-rejecting, the check consults this cache. If the allocation was confirmed eligible within grace_period, the receipt is accepted.

Both fixes source grace_period from recently_closed_allocation_buffer_secs - no new config surface. Behaviour beyond the grace period is identical to current.

What this does and doesn't fix

Window	Before this PR	After this PR
Minutes 0–5 (monitor polling gap)	Indexer-service rejects receipts and drops signers	Receipts accepted, responses correctly attested
Minutes 5–60 (gateway propagation lag)	Gateway errors persist	Gateway errors persist - not fixed here

The 55-minute tail of the outage requires the gateway to either sync its network subgraph faster or stop issuing receipts with stale allocation IDs after a reallocation. That is a gateway-side fix.

Safety

• No payment path changes. Accepting receipts for recently-closed allocations within the grace period is consistent with existing recently_closed_allocation_buffer_secs semantics - tap-agent already aggregates RAVs for these.
• AttestationSigner construction is deterministic and purely local. Retaining it for the grace period does not affect signing correctness.
• Hard-reject resumes after grace period expiry, identical to current behaviour.
• AllocationEligible::new defaults to 3600s. Existing call sites require no changes.

Files changed

• crates/monitor/src/attestation.rs
• crates/service/src/tap/checks/allocation_eligible.rs
• crates/service/src/service/router.rs
• crates/service/src/tap.rs

[ayushsingh82]

Thanks for the detailed write-up and tests — this is a real gap worth fixing.

One concern: the two fixes in this PR don't actually share the same "grace period" semantics, even though they're both sourced from recently_closed_allocation_buffer_secs.

• In crates/monitor/src/attestation.rs::modify_signers, the tombstone timer starts the moment an allocation ID disappears from the watch channel (i.e. real closure/first-missed-poll time). Every recently-closed allocation gets the full grace period, unconditionally.
• In crates/service/src/tap/checks/allocation_eligible.rs::AllocationEligible::check, recently_seen is only populated inside the in_active_set branch — i.e. only when a receipt happens to arrive while the allocation is still active. The clock there is tied to "last time a request for this allocation happened to hit the service," not to closure time.

Concretely: if an allocation has no traffic in the moments right before it closes, or if indexer-service restarts near a reallocation (wiping the in-memory recently_seen map), AllocationEligible gives zero grace period — the exact receipts this PR is meant to rescue (arriving in the 0–5 min post-reallocation window) get hard-rejected anyway, since there's no prior recently_seen entry to check against.

So the results table in the PR description ("Minutes 0–5: Receipts accepted, responses correctly attested") only holds if there happened to be recent traffic on that allocation before closure — it isn't guaranteed by the mechanism as written.

Suggested direction: anchor AllocationEligible's grace window to the allocations watch channel itself (mirror the tombstone-on-disappearance approach in attestation.rs) rather than lazily populating recently_seen only on request. That would make both fixes measure the same window and guarantee the fix even for low/no-traffic allocations.

(Everything else looks solid — no deadlocks, both maps are bounded/pruned, tests pass, CI green.)