feat(sim): the demo script is keyed on the project the prompt names, so a new project is data

The scripted proposer answered one hard-coded pair of proposals. A second project meant a second
hand-written selector, written under demo-week time pressure -- the risk the week plan names
explicitly (§4, risk 2). It is now a registry: `ScriptedCandidate` entries selected by
`scripted_proposer`, plus `project_id` as an argument to `simulate_learning_loop`.

The open decision was WHAT identifies the candidate in the prompt blob; the plan flagged it as
unverified, so it was measured. Two prompt shapes reach the selector: the debate prompt carries the
whole bundle context, the generation prompt carries `Project: {id} - {name}` plus -- as its context
-- the debate output, which is the selector's own earlier reply. So the cost code and the measure
name are present in the generation prompt only because the script put them there; keying on them
would key the script on its own output. The project id is the one identifier both shapes carry and
the framework stamps.

Validation, never repair: no match, or more than one, raises `ScriptedCandidateError`. A default
reply would answer an unregistered project with another project's numbers, which on screen is
indistinguishable from a correct run; an ambiguous blob is a data problem that must surface at the
rehearsal rather than be decided by registry order.

Load-bearing MEASURED against the whole suite, five mutations all red plus a green control: detach
the project keying - one global flip key - fall back on an unknown project - first-match on an
ambiguous prompt - detach the `project_id` argument. The flip-key test was rewritten mid-measurement
because its first form asserted on the FIRST registry entry, where "the matched candidate's key" and
"candidates[0]'s key" coincide -- it could not separate the two implementations, and proved nothing.

766 passed / 4 skipped. Simulation still exits 0, still prints eight labelled steps, still
byte-identical across two runs.

[skip-docs] README is deliberately untouched: O4 defers the README rewrite to 14-15 August, after
the demo has produced the evidence for the level-2 claim. CLAUDE.md carries the invariant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XoHJCKBTjFKcjsfEQyGbzh

CLAUDE.md

@@ -267,6 +267,25 @@ Python ≥3.10. MAF (`agent-framework-core` 1.9.0). Pakkehåndtering: `uv`. To b
   lever på Claude-SDK-siden (minimal API-kjøring). Skriptet klient = MAF-side stillas, IKKE delt
   (`shared/` forblir framework-nøytralt). Kjøres `uv run python -m portfolio_optimiser.simulation`.
   Load-bearing: `tests/test_simulation_loadbearing.py` blir RØD når promoteringen detaches.
+- **Det skriptede manuset nøkles på PROSJEKT-ID-en, og det er MÅLT:** `scripted_proposer(candidates)`
+  bygger simuleringens proposer fra et `ScriptedCandidate`-register, så et nytt prosjekt er en
+  data-oppføring (demo-uke-plan §4 risiko 2) — ikke et andre håndskrevet manus. **Hvorfor ikke
+  kostkode/tiltaksnavn:** to prompt-former når selectoren — debatt-prompten bærer hele
+  bundle-konteksten, mens genererings-prompten (`generate._build_messages`) bærer
+  `Project: {id} - {name}` pluss *debatt-outputen* som kontekst, altså selectorens EGET tidligere
+  svar. Kostkode og tiltaksnavn står derfor i genererings-prompten kun fordi manuset selv la dem
+  der; å nøkle på dem ville nøklet manuset på sin egen output. Prosjekt-ID-en er den ene
+  identifikatoren BEGGE former bærer og som RAMMEVERKET stempler. **Validering, ALDRI reparasjon:**
+  null treff — eller mer enn ett — raiser `ScriptedCandidateError`; et default-svar ville besvart et
+  uregistrert prosjekt med et ANNET prosjekts tall, som på skjermen er umulig å skille fra en riktig
+  kjøring, og en tvetydig blob er et DATA-problem som skal falle på generalprøven, ikke avgjøres av
+  register-rekkefølgen. `flip_key` MÅ være fraværende fra bundelen (ellers bærer forsøk 1s prompt
+  den allerede). `simulate_learning_loop` tar `project_id` ved siden av `bundle_dir`. Load-bearing
+  MÅLT (`tests/test_content_keyed_script_loadbearing.py`), fem mutasjoner alle røde + grønn
+  kontroll: detach nøklingen · én global flip-key · fallback ved ukjent prosjekt · første-treff ved
+  tvetydighet · detach `project_id`-argumentet. **Flip-key-testen ble skrevet om under målingen** —
+  første form asserterte på FØRSTE register-oppføring, der «den matchede kandidatens nøkkel» og
+  «`candidates[0]`s nøkkel» sammenfaller; den kunne ikke skille de to implementasjonene.
 - **Delt ekspert-persona som Agent Skill (§8, framework-nøytral):** ekspert-reviewer-personaen bor i
   `shared/skills/expert-reviewer/` (`SKILL.md` + `references/example-verdict.json`) og er den ENE
   delte artefakten begge stacker instansierer reviewer-en fra. `shared/` forblir REN DATA — MAF-siden