findings-spinelisted

The `mantis_findings` MCP server owns finding state (PRD section 9, FR-9.*). Findings live in an append-only event log at `.codex/findings/events.jsonl`, not in your message history -- so a run is reconstructable and nothing is silently dropped. Never track confirmed/rejected findings only in prose; write them through this service so ids, lifecycle, severity, evidence, and grade are authoritative. Lifecycle (PRD section 5): `candidate -> confirmed | rejected -> exploited -> fixed -> verified`. `rejected` is terminal. Detect is generous, Validate is ruthless. When to call each tool: - **`finding_create`**: the moment Detect/Recon surfaces a plausible weakness, register it as a `candidate`. Do NOT self-censor false positives at this stage -- high recall is the point; killing false positives is Validate's job. Pass `vuln_class`, a one-sentence `claim`, and `location`. You get back a stable `id` -- use it in every later step. - **`finding_update` to `confirmed`**: only after attacker-simulation. The service refuses to confirm without reachability evidence -- pass `reachability_note` (how attacker-controlled input provably reaches the sink) or attach `evidence` first. "No proof -> no confirm." - **`finding_update` to `rejected`**: requires `rejected_reason` naming the SPECIFIC roadblock (auth gate, sanitizer/parameterization at the sink, provably-unreachable path, self-only harm, framework auto-protection). The service rejects "seems safe" by requiring the field -- but you must