feat: ingestion + retrieval interface improvements (append, filter, webhook, verify)

[zenprocess]

Filed from zenprocess/switchyard — full spec at specs/089-afterburn-ingestion-retrieval/spec.md.

Context

Afterburn currently exposes GET /afterburn + batch-replace POST /afterburn. For the switchyard parameter-evolution loop (zenprocess/switchyard spec 088), this is too coarse:

1. No append-per-finding — every producer stages full batches.
2. No filtered retrieval — clients pull all 572 findings + 168 history entries.
3. No subscribe — consumers must poll.
4. No per-finding verification persistence — batch-replace nukes verification state.

Proposed changes (detail in linked spec)

• US-A: POST /afterburn/findings single-finding append, returns finding_id.
• US-B: GET /afterburn/findings with filters (project, type, since, arm_id, signature_characteristic, pagination).
• US-C: POST /afterburn/subscribe webhook endpoint with HMAC-signed delivery; filter-based.
• US-D: PATCH /afterburn/findings/{id}/verify per-finding verification (confirmed/rejected/duplicate/applied), persists across batch-replace.
• US-E: OpenAPI spec regeneration.

Why this matters

Switchyard spec 088 (parameter evolution via Optuna) needs filtered + subscription-driven retrieval to react to patterns in near-realtime instead of polling full batches. US-D closes the loop — when switchyard applies a mutation triggered by a finding, it can PATCH the finding to status=applied.

Non-ask

Backward compatibility preserved: existing POST /afterburn batch-replace keeps working for afterburn-worker.

Estimate

~300 LOC impl + ~100 LOC tests. Out of scope for switchyard; filed here for zenprocess-level prioritization.

---

Cross-links:

• Switchyard spec 088 (parameter evolution — primary consumer)
• Switchyard spec 090 (`zd agents evolve` CLI — consumes US-B + US-D)
• Switchyard memory: project_hermes_supremacy_vision.md (end-state architecture)