Carry forward _forget_mn_key and the KF kf_action diagnostics

[jehanazad]

Why

#303 and #305 were closed on 2026-09-10: their policy changes (the orphan rule, the KF hold and uncertainty-sourced R) were measured against their own live captures and against what main did since (#310, #329, #331) and lost. Each carried one piece that is worth having regardless of policy. This is those two pieces, written against current main rather than rebased through the conflicts.

What

• _forget_mn_key(old_key) in backend/services/tasks/solver.py — factors the four-store removal (entry, anomaly hex, _MN_POS_HISTORY, Kalman state) the supersession loop did inline. The loop now calls it; no behaviour change. Any future removal path goes through it, or the next key minted at the same place inherits the dead one's filter.
• kf_action / kf_d2 / kf_innov_m stamped on every return path of track_filter._smooth_kf (init, passthrough, smoothed, manoeuvre_rescued, reanchored) and copied onto the solve-history record beside kf_pos_sigma_m. manoeuvre_rescued is new relative to Hold established dark tracks against outlier solves (TRACK_KF_OUTLIER_MODE, TRACK_KF_R_SOURCE) #305 and names Display filter: adapt process noise to manoeuvres instead of re-anchoring #310's retry branch; kf_d2 is the base-Q innovation that triggered the retry, so a rescued update still shows the surprise. _predict_update returns the innovation magnitude as a fourth value for the stamp. None on rejects and in off/ewma mode. Stamped in place on the passthrough paths, which return the caller's dict by identity.
• Not carried: Hold established dark tracks against outlier solves (TRACK_KF_OUTLIER_MODE, TRACK_KF_R_SOURCE) #305's kf_held / kf_reanchored counters (filter_stats() already counts re-anchors and rescues) and Retire orphaned dark keys behind DARK_FOLLOW_ORPHAN_MODE #303's orphaned_keys history field.

What this buys: a capture on today's main can say how each published dark position came about — how many bad joins on established keys arrive via manoeuvre_rescued vs reanchored vs smoothed — without flipping any policy. That is the measurement #305's cap20 could not make, and the one any future outlier policy should be designed from.

Verified

• tests/test_track_filter.py — new TestKfActionStamp (4): every path stamped, the ten-kilometre re-anchor carries its breaching d2 and ~10 km innovation, the manoeuvre rescue is stamped as such with d2 > gate, off mode does not stamp.
• tests/test_mn_lifetime.py — new TestForgetMnKey (2) and TestHistoryRecordKfAction (2).
• Targeted set (test_track_filter test_mn_lifetime test_solver_anchor test_solver_stats test_dark_follow test_dark_key_track_continuity test_mlat_history test_feed_multinode test_known_track_hold test_known_track_follow): 405 passed, 1 skipped (Stone-Soup oracle, not installed locally), exit 0.
• pre-commit run on the four changed files: all five hooks pass.
• Submodule pins unchanged.

🤖 Generated with Claude Code

[claude]

Claude finished @jehanazad's task in 1m 23s —— View job

---

Todo

• Gather context (PR diff, description, CLAUDE.md)
• Read changed files (solver.py, track_filter.py, tests) against origin/main
• Review _forget_mn_key extraction for behavior parity
• Review kf_action/kf_d2/kf_innov_m stamping across _smooth_kf return paths
• Review test coverage additions
• Check contract/regeneration implications (CLAUDE.md gate)
• Post final review

Summary

Re-reviewed against origin/main (this synchronize only merged in unrelated main history — git diff between the feature commit and HEAD on the four changed files is empty, so the substantive diff is unchanged from the last review). Confirms the same conclusion: both pieces do what the description says, no correctness issues found.

_forget_mn_key (backend/services/tasks/solver.py:1820-1836) — a straight extraction of the four-store removal (multinode_tracks, anomaly_hexes, _MN_POS_HISTORY, track_filter.drop_key) the supersession loop previously did inline. Verified the single call site (solver.py:3943) sits inside the with _MN_TRACKS_LOCK: block opened at solver.py:3769, matching the docstring's claim that the caller holds _MN_TRACKS_LOCK and that _MN_POS_HISTORY_LOCK is taken inside — consistent with the lock order documented at solver.py:3776-3778 and used everywhere else in the module. No behavior change.

kf_action/kf_d2/kf_innov_m stamping (backend/services/track_filter.py) — traced every return path of _smooth_kf:

• init (first solve, gap re-init): stamped with d2=None, innov_m=None — nothing was computed.
• passthrough (dt ≤ 0 dedup): same.
• reanchored: stamped with the pre-branch (base-Q) d2_observed/innov_m — matches "a re-anchor carries the breaching d2."
• manoeuvre_rescued/smoothed: action set on the retry-success branch, falls through to the single _stamp(smoothed, action, d2_observed, innov_m) at the bottom, still using the base-Q d2_observed — matches "a rescued update still shows the surprise."
• off/ewma modes (track_filter.py:996-1003) return before ever calling _smooth_kf, so kf_action is absent for them and for rejects, consistent with _record_solve_history's r.get(...) copy in solver.py:2926-2929.

_predict_update's new fourth return value (innov_m) is correctly discarded (_) on the manoeuvre-retry call — only the base-Q attempt's innovation is stamped, matching the description.

Tests — TestForgetMnKey (2) covers all-four-stores-cleared and unknown-key no-op. TestHistoryRecordKfAction (2) covers the published/reject history record. TestKfActionStamp (4) covers every _smooth_kf path, the ten-kilometre re-anchor's breaching d2/innovation, the manoeuvre rescue's base-Q d2 above gate, and off-mode's absence of the stamp. Assertions line up with the actual implementation (e.g. "smoother" not in out for the raw-passthrough re-anchor case).

CLAUDE.md gate — no /v1/nodes routes, models, or node_config.py bindings touched, so no contracts/nodes-v1.openapi.yaml regeneration is required.

Not independently verified: no pytest/pre-commit available in this sandbox (no approved tool access to invoke the interpreter or package manager), so this is static tracing of the diff, not a re-run of the suite. The PR body's reported results (405 passed, 1 skipped; all five pre-commit hooks pass) are plausible given the diff but unverified by me.

No changes requested.