Add claim upkeep

[kalrashivam]

Auto-claim via a dedicated keeper

Adds keeper-driven claim settlement on top of fix_withdraw_request's crystallization work.
Until now, claimEpochAssets/batchClaimEpochAssets were the only way to get paid, and both
require msg.sender == claim.user — a user (or someone holding their key) had to submit their
own transaction. This PR adds an automatic path without removing that one.

What changed

EpochedQueueModule.keeperSettleClaims(epochId, claimIds) — new function, pays each claim
directly to claim.user regardless of who calls it. Self-claim is untouched and remains the
permissionless fallback if no keeper is run, or one lags; a claim settled by either path is a
no-op for the other (idempotent on EpochClaim.claimed).

Deliberately atomic — not try/catch-per-claim internally. Swallowing a failed transfer inside the
loop would let claim.claimed get set without the money actually moving, which is a fund-loss
bug, not a liveness nicety. If any claim in a batch fails, the whole batch reverts; the automation
layer (below) is where liveness/retry belongs.

src/automation/ClaimSettlementUpkeep.sol — new, separate Chainlink-Automation-compatible
contract. Deliberately not an added Op on the existing VaultUpkeep:

VaultUpkeep.checkUpkeep is a strict single-op-per-tick priority chain (EPOCH_FUND > EPOCH_CLOSE > RECONCILE > CRYSTALLIZE > REBALANCE > STRATEGY_REBALANCE > DEPLOY > REALIZE), each
tier already cooldown/starvation-tuned against the others. Claim settlement is a different shape
of work — not one vault-wide state flip but a per-user backlog needing its own pagination cursor
across many ticks. Slotting it into that chain would either starve it (low priority, rarely
reached on an active vault) or destabilize the existing tuning (high priority). A separate
contract gets its own Chainlink registration and cadence instead, and doesn't touch VaultUpkeep
at all.

• Scans forward from a persistent (epochId, claimId) cursor, bounded by owner-configurable
  maxClaimsPerUpkeep (default 20) / maxScanPerUpkeep (default 200, so a long run of
  already-claimed IDs can't blow the gas budget).
• performUpkeep failure (try/catch — the same liveness pattern VaultUpkeep already uses)
  leaves the cursor untouched; it retries the same batch next tick.
• Owner escape hatch, excludeClaim(epochId, claimId, bool): a claim whose owner can't receive
  the asset would otherwise block its whole batch forever, atomically, on every retry. Excluding
  it only affects this keeper's scan — the user can still self-claim if their address later works.

Test infra fix: test/helpers/CoreHarness.sol wires module selectors from a hand-maintained
list, not from SelectorLib — it was also missing rollCapEpochIfNeeded (added in the parent
branch), so no test had exercised that as a standalone external call until now. Both gaps closed.

Selectors

QUEUE_MODULE_SELECTORS: 10 → 11 (+keeperSettleClaims).

Tests

12 new (test/unit/automation/ClaimSettlementUpkeep.t.sol):

• payout goes to claim.user, never the keeper caller
• batching across multiple ticks with a bounded batch size
• cursor correctly skips a still-unfunded epoch to find work in a later funded one
• idempotency against self-claim, in both orders (keeper-first and self-claim-first)
• a failed performUpkeep leaves the cursor in place and retries
• the exclusion escape hatch

Full suite: 991/991 passing. EpochedQueueModule 17,521/24,576 bytes (EIP-170 margin: 7,055).

Out of scope / follow-up

• Not deployed or registered with Chainlink Automation.
• rollCapEpochIfNeeded (from the parent branch) still isn't wired into any keeper — separate
  open decision, not addressed here.

[kalrashivam8375]

Addressed the funding and claim-settlement review findings in 8e64fc4.

Funding and cap handling

• N1: Unfunded cohorts use assets and liabilities net of reservedForClaims, so the second cohort can fund before the first claims.
• N2: Haircut crystallization requires valid navStatus(), including after liquidity reconciliation. Invalid attempts emit EpochFundingNavInvalid and leave the epoch Closed.
• A2: Standard/instant requests, deposit/mint, force exits and funding roll the cap epoch before changing assets or supply. Zero epoch duration safely skips rollover.
• B2: Instant requests refresh warm NAV before checking eligibility and pricing.
• Dynamic cap parameters are ignored by enforcement and the lens; capPerEpochBps controls the cap.
• Funding/claim shortfall tolerance is limited to one underlying base unit. A new regression verifies that a two-unit illiquid remainder leaves the epoch Closed without writing down liabilities.

Claim automation and FeeCollector

• performUpkeep recomputes the scan from on-chain state and ignores caller-supplied cursor data.
• A bounded circular scan revisits skipped unfunded epochs and retryable claims.
• Failed batches fall back to individual claim calls so healthy claims can settle. Failed claims receive a one-hour retry delay; unsuccessful/maintenance runs have a one-minute cooldown.
• checkUpkeep returns false while funded claims are paused; performUpkeep also checks the pause.
• harvestQueued recognizes keeper-settled claims, removes their pending entries and distributes available underlying. It also clears settled entries when the underlying has already been distributed.

Documentation and validation

• Aligned economic-exit.md with request-time pricing, immutable cohort recovery and current cap/keeper behavior. Removed the superseded banners from audit-scope.md, fee-policy.md and modules.md, and cleaned reviewer attributions and stale historical wording in comments/docs.
• Local core/automation run: 655 passed, 0 failed. Final economic-exit regression run, including the new two-unit boundary test: 21 passed, 0 failed. These runs overlap; fork tests were not run.

These fixes are currently on this PR's branch. The requested CoreHarness change split into #19 has not been performed; PR history has not been rewritten.