fix: prevent silent keyed decision closure failures

[mremond]

A malformed keyed status line was classified silently, so decisions could stay open forever — or close when they should not.

The bug

bin/fm-classify-lib.sh derives both the verb and the key from everything before the first colon, rather than from the documented grammar <verb> [key=<slug>]: <note>. Two shapes fail, in opposite directions:

resolved corr=abc123 [key=x]: …     → verb reads "resolved corr=abc123" → key x stays OPEN
needs-decision: [key=x] …           → key token invisible → filed under "default"

The second is the nastier one: the closing line is well-formed, so re-reading your own work reveals nothing — the defect sits in a line written earlier by someone else. And the fold prints the key token from inside the note, visually confirming a match that does not exist.

Both were observed on real tasks hours apart. Nine decisions were affected.

Why it matters more than the noise: the author believes the decision is closed while the fold keeps shouting. An alert that cries wolf on every wake gets skimmed — which is exactly when the one genuinely open decision goes unnoticed. That is the failure this fold exists to prevent.

What changed

• Verb and key are parsed against the grammar instead of the whole prefix.
• An out-of-grammar line is refused and reported, never classified silently.
• A closure matching no open key is reported as an anomaly — previously it produced nothing at all, and reporting it would have exposed the second shape in one day instead of two.
• The incremental cursor is versioned, so records written before this lands are re-read once rather than staying stuck on the old parse.
• bin/fm-brief.sh taught the failing shape in three generated briefs (“append resolved: … then add the key”). Corrected — the token is now shown in its required position.

Deliberately unchanged

• done [key=x]: still does not close a key. A terminal line must never cancel an open decision.
• A legitimate activity closure (working [key=p]: → resolved [key=p]:) is not an anomaly: the unmatched-close check consults both the decision fold and the activity fold before reporting.
• status_is_captain_relevant() shares this parser; its free-text fallback is unchanged, and covered.

The obvious fix — take the first word — was rejected: prose beginning resolved the conflict by hand: would then close a key it never claimed. A wrongly closed decision disappears with no review, which is worse than the noise.

Verification

Both directions are tested: a legitimate token-bearing closure must close; prose beginning with a verb word must not. Plus post-colon keys, unmatched closures, the done non-regression, and cursor replay bounded to snapshotted bytes.

Suites: fm-wake-drain-open-decisions, fm-wake-drain-open-decisions-cursor, fm-watch-triage, fm-brief. Drain output captured twice over crafted incident logs to confirm each anomaly is reported exactly once.

Pipeline

Updates from git push no-mistakes

intent ✅ · rebase ✅ · review ✅ (3 findings, auto-fixed) · test ✅ · document ✅ · lint ✅ · push ✅