review: prove value or remove the dormant procedural features (#615 + #641)

[itlackey]

Decision needed

Two improve-pipeline features ship default-OFF and have never demonstrated value in prod. Decide per feature: prove it (turn on, measure) or remove the dormant code. Don't carry unproven, switched-off machinery indefinitely.

In scope

• feat(improve): procedural compilation from successful sequences #615 — procedural compilation (src/commands/improve/procedural.ts, default-off via improve-profiles.ts). Known to over-fit one-off single-project sequences; procedural: over-fits one-off single-project sequences (recurrence needs cross-project + identifier abstraction + generalizability gate) #634 tracks the (M–L) fix for that. So the real question is upstream: is procedural worth the investment at all, or should feat(improve): procedural compilation from successful sequences #615's code + procedural: over-fits one-off single-project sequences (recurrence needs cross-project + identifier abstraction + generalizability gate) #634 be cut?
• triage: procedural-aware floor for residual low-signal sessions (sequence LAST, after origin filter) #641 — procedural-aware triage floor (src/commands/improve/triage.ts, opt-in / default-off). Its own body calls it the lowest-confidence lever, highest false-negative risk; the big cost mass was the (reverted) review-subagent origin filter.

How to decide (don't guess — measure)

For each: either (a) enable in a shadow/eval window and measure accepted-change-rate / coverage (NOT promotion volume — see akm-improve-success-metric), keeping it only if it clears a bar; or (b) remove the dormant code and close the feature. Default-off code is cheap to keep but costs clarity and invites half-finished follow-ups (#634).

Acceptance

• A written keep/cut decision for feat(improve): procedural compilation from successful sequences #615 (and by extension procedural: over-fits one-off single-project sequences (recurrence needs cross-project + identifier abstraction + generalizability gate) #634) and for triage: procedural-aware floor for residual low-signal sessions (sequence LAST, after origin filter) #641, backed by eval/live numbers, not estimates.
• Whatever is cut is removed cleanly (code + tests + config + issue closure); whatever is kept gets a concrete path to default-on.

Relates to #615, #634, #641. Context: akm-recombine-procedural-noise, akm-verify-impact-against-artifacts, akm-improve-success-metric.