Proposed work: add safety-cap guards to claim inventory

[elianguitarra]

Problem

python scripts/claim_inventory.py --repo ramimbo/mergework can silently produce an incomplete live inventory if the GitHub list calls hit their configured limit.

The script currently uses one shared GH_LIMIT = 200 for:

• public API reads: /api/v1/bounties?limit=200 and /api/v1/activity?limit=200;
• gh issue list --limit 200 before viewing bounty issues;
• gh pr list --limit 200 before viewing PR details and review comments.

If the repo reaches that cap, the live report can omit bounty issues, PRs, reviews, review comments, or claim surfaces without warning. That is risky for a claim/payment inventory tool because an omitted claim can look like no claim exists.

Current evidence

Code references on current main:

• scripts/claim_inventory.py defines GH_LIMIT = 200.
• load_public_api_state() requests bounties and activity with that limit.
• load_live_inventory() passes the same limit to gh issue list and gh pr list.
• Unlike scripts/pr_queue_health.py and scripts/review_bounty_candidates.py, claim_inventory.py does not fail fast when a live GitHub list reaches its safety cap.

Related existing pattern:

• scripts/pr_queue_health.py has GH_PR_SAFETY_CAP / GH_ISSUE_SAFETY_CAP and raises if the list length reaches the cap.
• scripts/review_bounty_candidates.py raises if gh pr list reaches GH_PR_SAFETY_CAP.
• scripts/submission_quality_gate.py reports load warnings when GitHub list collection hits safety caps.

Proposed work

Add explicit cap handling to scripts/claim_inventory.py live collection so operators do not trust truncated inventory results.

Smallest useful implementation:

• Split the shared GH_LIMIT into clear constants for public API read limits and GitHub collection safety caps, or otherwise document the distinction.
• After gh issue list, fail fast or surface a clear warning if the number of returned issues reaches the issue safety cap.
• After gh pr list, fail fast or surface a clear warning if the number of returned PRs reaches the PR safety cap.
• Keep fixture/input mode unchanged.
• Preserve the script's read-only behavior.

Expected value

This makes the claim inventory safer during busy bounty rounds. Maintainers and agents can tell the difference between:

• “the inventory found no additional claim surface”; and
• “the inventory might be incomplete because GitHub collection reached the configured cap.”

That reduces duplicate submissions, missed pending payouts, and overconfident audit reports.

Suggested reference tier

100-500 MRWK: small script hardening with focused tests.

Possible acceptance criteria

• Live --repo mode detects cap saturation for issue and PR list calls.
• The error/warning message names the cap and recommends paginated collection before trusting the report.
• Tests cover issue-list cap and PR-list cap behavior.
• Existing fixture/input mode and markdown/JSON output remain unchanged when caps are not reached.
• No GitHub mutation, treasury, ledger, wallet, payout, or proof behavior changes.

Evidence or tests required

• Unit tests that monkeypatch _run_gh_json to return exactly the cap count for issues and PRs.
• Existing claim inventory tests still pass.
• Optional CLI smoke check for scripts/claim_inventory.py --help remains green.

Duplicate search

• Searched open/all issues for claim inventory proposed work: only related item found was Proposed work: classify pending payout proposals in claim inventory #678, which covered pending payout classification, not cap/truncation safety.
• Searched open/all issues for safety cap proposed work, pagination cap proposed work, and GH_LIMIT proposed work: no matching proposed-work issue found.
• Related but not duplicate: Proposed work: Add proposed-work intake triage report #672 proposed-work triage report.
• Related but not duplicate: Proposed work: add review-bounty claim saturation checks #797 review-bounty claim saturation checks.
• Related but not duplicate: Proposed work: filter bounty issues from proposed-work triage #803 proposed-work triage filtering.

Out of scope

• No full pagination implementation required for the first useful version.
• No changes to payment status classification, pending payout matching, ledger state, proof generation, wallets, balances, or treasury execution.
• No mutation of GitHub issues, PRs, comments, labels, bounties, or proposals.
• No claims about received, withdrawable, exchangeable, bridged, or cash-out value.

Refs #932