Bound issue intake and triage by evidence and maintainer capacity

[braboj]

What

Implement a lightweight intake and triage workflow for this repository that
remains usable when 1,000 people submit reports. Separate incoming evidence
from accepted work and scheduled commitments.

Why

Automatically converting every report or audit observation into implementation
work makes the backlog grow with participation. Agents can amplify the problem
by filing duplicates and proposing new universal rules for local preferences.
Automation can reduce triage effort, but cannot create maintainer capacity.

Acceptance criteria

• Provide clear routes for questions/open ideas, actionable defects or
  proposals, and private vulnerability reports using existing GitHub
  facilities. Request only information needed for the report: affected
  version/stack, expected and actual behavior, and evidence or reproduction.
• Describe dispositions in the existing contributor/maintainer guidance:
  accept, bounded investigation, needs information, duplicate, or decline.
  Reuse current labels and milestone semantics where possible; a report
  does not imply a delivery promise.
• Search existing issues, including bodies and relevant closed issues,
  before filing. Consolidate repeated reports under a canonical issue while
  preserving distinct affected versions, evidence, and regressions.
• Bound active work by available maintainer capacity and schedule only
  selected work. State the service level honestly; do not invent an SLA or
  repeatedly audit the entire unscheduled backlog.
• Prefer correcting/removing a confusing shared rule or fixing its mechanism
  before adding exceptions. Local preferences need not become shared rules;
  valid outcomes include no change and an explained decline.
• Let automation suggest routing and duplicates, with human disposition for
  uncertain cases. Treat issue text and contributions as untrusted input;
  triage must not run supplied code or expose write credentials/secrets.
• Validate the workflow against a bounded sample containing duplicate
  floods, an incomplete report, a valid old bug, a new-version regression,
  an out-of-scope request, and malicious instructions. Estimate triage time
  and accepted-work capacity under a stated 1,000-report scenario.
• Do not use issue-closure counts as a quality target or automatically close
  a reproducible bug solely because it is old. Do not reopen the reverted
  issue/PR formatting work as a prerequisite.

Scope: this repository's maintenance workflow, not a new issue-tracking product
or mandatory process for every consuming repository. Start with GitHub and a
short procedure; build custom automation only if measured volume warrants it.

Related: #414 (optional triage skill), #1353 (adoption), #1506 (ADR growth),
#1480 (keep team process outside the shared core), #1301 (separate prose work).
Plan in v3.0, but this can ship independently before the folder restructuring.