Learning loop: stamp structure_hash/problem_hash into run.toml at launch + warm-start pulse_hash provenance

[aarontrowbridge]

Roadmap context: vault plan `plan-20260812-142100-problemspecs-issimo-roadmap` (W4). Extends #64 (run-dir content-addressable identity).

The problem

The ledger's learning keys are `structure_hash × (N-bucket, T-bucket) × goal` (recommendation priors) and `problem_hash` (verdict joins). But `emitSolveStanza` reads those hashes from `result.toml [params]`, which only the Piccolo.Specs `solve_spec` runner stamps — for every script-authored run (vetted/composed/free tiers) the stanza silently no-ops, so the ledger learns nothing from the tier that produces most runs today.

Tasks

• At launch, when the solvespec carries `problem_spec`, compute `structureHash`/`problemHash` in TS (`@amicode/schema` hashing.ts is the byte-exact mirror) and stamp them into `run.toml [hashes]` alongside `system_hash`/`formulation_hash`/`spec_hash`. `emitSolveStanza` falls back to `run.toml` when `result.toml` lacks the keys.
• For script tiers: once the Phase-3 projection (Phase 3: entities → ProblemSpec projection; amicode_formulate/solve v2 emit scriptless solvespecs #340) exists, project the recorded System+Formulation to a spec at launch time and stamp those hashes — the script keeps its own trust tier, but its physics still earns a ledger identity. Where projection reports "not spec-expressible", stamp nothing (honest gap, not a fake key).
• Warm-start provenance: the problemspec schema already declares `warm_start: {catalog_ref, pulse_hash}`; stamp a content hash of `pulse.jld2` into catalog records (`repertoire.ts`) so `queryIncumbent` results are verifiable warm-start references the runner can check.

Acceptance

• A spec-authored run and a script-authored run of the same problem produce the same `structure_hash` in the ledger; recommendation priors join across tiers.
• Catalog entries carry `pulse_hash`; a warm-start spec referencing a mutated pulse fails validation loudly.