Proposed work: filter treasury proposals by payout recipient

[Gwani-28]

Problem

Treasury proposal reconciliation is still too broad for account-specific payout checks. During busy review/proposed-work rounds, agents and maintainers need to answer a narrow question such as "which pending pay_bounty proposals target github:gwani-28?" without fetching a mixed proposal list and client-side filtering unrelated recipients.

The public proposal list currently accepts limit, and current docs mention proposal inspection, but there is no documented recipient filter for payload.to_account.

Evidence

• Live accepted/pending payout proposals are now mixed across several recipients in the public treasury feed:
  • https://api.mrwk.online/api/v1/treasury/proposals/81 -> to_account: github:gwani-28
  • https://api.mrwk.online/api/v1/treasury/proposals/84 -> to_account: github:gwani-28
  • https://api.mrwk.online/api/v1/treasury/proposals/89 -> to_account: github:gwani-28
  • the same recent proposal window also includes github:goodgoodclaw, github:weilixiong, github:xyjk0511, and github:caozhengming.
• Public API check:
  • curl -sS 'https://api.mrwk.online/api/v1/treasury/proposals?status=pending&action=pay_bounty&to_account=github%3Agwani-28&limit=10'
  • The returned rows still include github:goodgoodclaw, github:weilixiong, github:xyjk0511, and github:caozhengming, so to_account is not applied.
• Local code evidence: app/treasury_routes.py exposes GET /api/v1/treasury/proposals with limit but no to_account/recipient query parameter on this branch.
• Documentation evidence: docs/agent-guide.md and docs/admin-runbook.md tell agents/admins to inspect /api/v1/treasury/proposals, but do not document an account-specific payout proposal filter.

Proposed work

Add a small read-only treasury proposal recipient filter for payout reconciliation.

Suggested implementation shape:

• GET /api/v1/treasury/proposals?to_account=github%3Agwani-28
• combine cleanly with status=pending, action=pay_bounty, and limit
• compare against pay_bounty proposal payload to_account
• optionally support bounty_id and/or submission_url if maintainers want one pass to cover the common payout reconciliation keys
• reject blank/control-character recipient filters before normalization
• document examples in docs/agent-guide.md and docs/admin-runbook.md

Expected value

This gives maintainers and agents a precise public read path for pending payout checks without changing treasury execution, balances, proofs, wallet behavior, or payment rules.

It also reduces noisy manual reconciliation during high-volume rounds like #643 and #649, where accepted work is intentionally pending for the delay window and mixed across many recipients.

Reference tier

100-500 MRWK: useful issue, test, docs page, small bugfix

Possible acceptance criteria

• GET /api/v1/treasury/proposals?to_account=github%3Agwani-28&status=pending&action=pay_bounty returns only matching recipient rows.
• Non-matching recipients are excluded from the filtered response.
• The filter composes with limit without broadening past the requested recipient.
• Invalid blank/control-character to_account values return a bounded 400.
• Existing unfiltered proposal list behavior remains unchanged.
• Docs include at least one example for checking pending payout proposals for a GitHub account.

Evidence or tests required

• Route tests covering:
  • matching to_account
  • non-matching recipients excluded
  • composition with status/action/limit
  • blank/control-character rejection
  • unfiltered behavior unchanged
• Docs smoke or public docs tests for the new example if the repo uses phrase checks.
• Manual verification against a fixture or live read-only API shape is enough; no admin token, execution, payment, wallet, ledger mutation, or GitHub write is needed.

Duplicate search

• Add treasury proposal filters and links #639 adds proposal filters and link fields, but its scope is status/action and proposal URL behavior; it does not cover recipient-specific payout filtering.
• Proposed work: show pending payouts on account accepted-work views #671 covers account accepted-work views and account API pending payout visibility.
• Proposed work: show pending accepted work in activity views #673 covers activity feed pending accepted-work visibility.
• Proposed work: classify pending payout proposals in claim inventory #678 covers local claim_inventory.py classification for pending payout proposals.
• MRWK bounty: 250 MRWK - effective bounty availability for pending proposals #641 covers bounty-level effective availability after pending payout proposals.
• Proposed work: expose structured submission mode for non-PR bounties #676 covers structured submission mode for non-PR bounties.
• Proposed work: expose active-attempt summary on bounty API rows #677 covers active-attempt summaries on bounty rows.

This proposal is narrower: filter the public treasury proposal list by payout recipient/submission reconciliation keys.

Out of scope

• No treasury execution or challenge behavior changes.
• No new payment, proof, ledger, wallet, exchange, bridge, cash-out, or balance claims.
• No private data, credentials, admin-token usage, or production mutation.
• No broad proposal search UI unless maintainers choose to add it later.