[feature] proposals: one path module owning all three proposal trees

[lec77]

Problem / use case

Knowledge of the ~/.skvm/proposals/ on-disk layout leaks across the storage seam:

• The round-N directory convention is inlined in src/jit-optimize/loop.ts:681, 831, 1081 and in src/proposals/storage.ts:612.
• src/bench/conditions.ts:483, 496 imports safeModelName and hand-builds aot-compile proposal paths.
• The optimize-lock path is constructed implicitly from the same key triple (harness, targetModel, skillName) without a named accessor.

A layout change (or the next schemaVersion migration) must be hunted across three subsystems.

Proposed solution

Deepen src/proposals/storage.ts into the single owner of layout for all three trees (jit-optimize, aot-compile, jit-boost):

• Export roundDir(proposalDir, n), evidenceDir(roundDir), optimizerDir(roundDir), lockPath(harness, targetModel, skillName), plus aot-compile and jit-boost path accessors for bench.
• safeModelName becomes internal — callers ask for finished paths, never apply escaping themselves.
• jit-optimize/loop.ts routes every snapshot through persistRound() instead of joining paths by hand.
• Round-trip tests for the path contracts (makeProposalId ↔ proposalDirFromId, lock-key association).

Alternatives considered

• jit-optimize tree only: smaller issue, but safeModelName stays exported and the bench aot-compile leak survives — half the locality win. Rejected.

Impact / blast radius

src/proposals/storage.ts, src/jit-optimize/loop.ts, src/bench/conditions.ts, proposals CLI in src/index.ts. No on-disk layout change — pure concentration of existing knowledge. Existing proposals remain readable; schemaVersion handling untouched.