feat(capture): correction-capture — auto-propose a draft claim when the user pushes back

[plind-junior]

the adapter captures tool outcomes passively (PostToolUse), but the single highest-signal event in a session — the user correcting the agent ("no, we deploy from main not release") — evaporates unless someone manually proposes a claim afterward. that's exactly the knowledge worth keeping, and it's the knowledge most reliably lost.

this proposes turning a detected correction into a proposal, automatically — never an auto-write. the correction lands in the pending queue as a normal draft for a human to approve or reject.

proposed surface

• a detection heuristic on the turn boundary (user negation / pushback / "actually…" immediately following an agent action) — cheap, no LLM required for the trigger.
• on trigger, call proposals.propose_claim(..., proposed_by="auto:correction", rationale="captured from user correction") to enqueue a pending claim quoting the correction, tagged so the reviewer sees its origin.
• driven from the same UserPromptSubmit hook as chore(deps): bump actions/setup-python from 5 to 6 #1 (it already sees the prompt), or via a small kb.capture_correction method the adapter calls; config capture.correction.enabled (default true) mirrors the posture of the existing ambient capture.

review gate & scope

this is the whole design constraint: correction-capture proposes, never writes. it has no code path to proposals.approve. the pending queue is the "draft" state — a human still drains it. because it routes exclusively through proposals.propose_*, it cannot create approved knowledge and cannot bypass the gate. dedup against existing approved claims via find_similar_on_propose (#147) so a repeated correction doesn't flood the queue. a per-session cap keeps an over-eager heuristic from swamping the reviewer.

acceptance criteria

• a detected correction enqueues a pending claim via proposals.propose_*; there is no call path to approve.
• captured proposals are tagged with a auto:correction origin visible in the queue.
• duplicate/near-duplicate corrections are suppressed via the feat: propose-time similarity warnings for duplicate claims #147 similarity path.
• a per-session cap bounds auto-proposals per run.
• capture.correction.enabled gates the behavior; default documented.
• tests/test_capture_correction.py asserts the propose-only invariant and the cap.
• make check green.

related: #1 (the hook that observes the turn), #319 (watched-inbox auto-propose), #320 (POST /ingest), #223 (salience).