[grove]

Separate numeric claim bound from maintenance batching

Based on draft React #14 feature head d70a73d. The real two-case outage fixture configures pg_react.batch_size=1, but the current runtime explicitly states that batch_size bounds maintenance, while ordinary managed job claims retain a separate pgreact.claim(max_items) admission argument.

This focused regression extends the established fresh/adjacent-upgrade claim_maintenance SQL fixture after the unchanged prior snapshot assertions:

• Prepare exactly two new independently pending deadline episodes using the public temporal registration/run API.
• Call pgreact.claim('bounded-1', 1, ...) and require exactly one lease and one remaining pending episode.
• Call pgreact.claim('bounded-2', 1, ...) and require a distinct second lease, zero remaining pending, and two successfully executed durable actions with exact original deadlines.
• Reject duplicate case actions, missing episodes, wrong lease ownership and any unexpected state progression; earlier invalid max_items=0/101 tests and lease/retry/role/upgrade fixtures remain unchanged.

This establishes numeric per-invocation public-claim bounds and simple backlog progress, not an independently sampled managed-worker per-cycle cap, FIFO fairness under mixed-load/claim races, release recovery bound, coherent restore/clone, or S1 60/min throughput. There is no production SQL/behavior, permission, dependency pin, archive or API change.

Draft pending exact-head CI. Merge only into issue/11-explicit-escalation-time after full CI. No main merge or release activation.