refactor(optimize): split 1948-line optimize.ts into focused modules

[tzone85]

What

src/optimize.ts was a 1948-line god file (2.4× a healthy ceiling) mixing constants, types, JSONL scanning, ~18 waste-detectors, session helpers, health math, and rendering. Split into 9 cohesive modules under src/optimize/, with optimize.ts kept as a barrel so the public API (runOptimize, scanAndDetect) and every re-exported symbol stay unchanged.

Module	Lines
constants.ts	186
types.ts	121
scan.ts	205
detectors-reads.ts	324
detectors-mcp.ts	419
detectors-ghosts.ts	174
detectors-sessions.ts	376
health.ts	94
render.ts	153
optimize.ts (barrel)	141

Behaviour-verbatim

Functions relocated verbatim (one detector incidentally Prettier-reformatted — token-identical, behaviour-neutral).

Verification

• tsc --noEmit clean; tsup build OK.
• 558 tests pass (incl. 76 optimize.test.ts + 32 optimize-fs.test.ts).
• HEAD-monolith vs this refactor → byte-identical CLI output on the same data.
• Reviewed: barrel-complete (all 36 exports reachable), no duplicate re-exports, single shared resultCache, no circular imports.

[ozymandiashh]

Thanks for tackling this — optimize.ts is genuinely oversized and a module split is welcome in principle.

Status: this needs a rebase before it can be reviewed/merged — it currently conflicts with main. src/optimize.ts moved substantially after this PR's base (2026-06-28):

• #604 feat(act): optimize --apply for config-class fixes + fix(act): scope project-scope removals, --yes safety, --only validation
• #606 feat(act): realized savings measurement (codeburn act report)
• a refactor(parser,optimize): export parseApiCall and lift session openers to constants

Because those landed directly in the file you're splitting, the 1948→9-module move no longer applies cleanly.

Not superseded — no competing split exists — but two asks before I run a full review:

1. Rebase onto current main and resolve conflicts so the split reflects the file as it is now (including the new act-related surface and the parseApiCall export).
2. Verify the barrel preserves the exact public API. optimize.ts staying a barrel is the right call, but please confirm every symbol currently imported from ./optimize.js elsewhere (incl. runOptimize, scanAndDetect, and anything #604/#606 added) is still re-exported, ideally with a note in the PR on how you checked (e.g. no change to the set of exported names).

A pure structural refactor of this size is only safe to merge when it's a provable no-op against the current tree, so once it's rebased and CI is green I'll do the full adversarial pass. Appreciate the effort here.