feat(outbox): every evaluated approach becomes something an expert can judge

A run commissioned to evaluate three approaches wrote ONE proposal artefact, so
only the approach it selected could ever receive a verdict. The other two were
evaluated, reported in the settlement, and then taught the learning loop nothing.

The defect class is a key collapse, and it had two halves — fixing either alone
leaves it intact:

* the WRITER wrote one pair per run, so the non-selected approaches never existed
  on disk;
* the READER (hitl._read_outbox_proposals) joins proposal to outcome on the
  run_id FIELD read from file CONTENT, never the filename. Three files sharing
  one run_id collapse onto one dict key, last write wins — so widening only the
  filename would have produced three artefacts and still one pending row. This is
  the S3.2 collision class: two rows under one key silently become one.

Artefacts are now keyed {run_id}-{approach_id}-*.json AND carry approach_id in the
payload; the join key is (run_id, approach_id). Two properties make them genuinely
judgeable rather than merely present:

* verdict_id is minted per approach (verdicts.verdict_key, the S3.2 content hash)
  — reusing the run's single id would let one delivered verdict clear all three
  from the queue;
* provenance.validator_decision follows ITS OWN approach — the run's stamp would
  report a rejected candidate as validated, and nothing downstream could correct it.

verdicts.verdict_key is public so a run can stamp the key a verdict WILL arrive
under without capturing a decision nobody has made; it delegates to _mint_id
rather than restating the hash (the (p) rule: one keying rule, one copy).

The per-approach set REPLACES the run-level pair rather than joining it — the
selected approach is already among them, and writing both would count it twice in
hitl pending. The selected one carries the run's final outcome, so the outbox can
never disagree with the RunResult; the others carry the validator's verdict, the
only falsifier that ran on them.

mandate.py is deliberately untouched: hanging a ValidatedProposal off a coverage
row would drag validator — and pulp — into a module kept to pydantic+stdlib for
D7 portability, so _evaluate_mandate returns the evaluated outcomes alongside.

Ran it, not just tested it: a real CLI run wrote six artefacts and hitl pending
listed three rows. It also showed the honest edge — three approaches that produce
an identical candidate share one content-hash key, so one verdict settles all
three. That is correct (they were one candidate), and it is now documented.

Load-bearing MEASURED (tests/test_a5_per_approach_artifacts_loadbearing.py) against
the whole 750-test suite, five mutations all red: detach the per-approach writer ·
drop approach_id from the join key · reuse the run's verdict id · reuse the run's
provenance stamp · widen the filename but not the payload. Control: on a full
detach exactly the 5 new tests fail and 745 pre-existing ones stay green — the
no-mandate path is inert, and writes neither the filename segment nor the field.

Docs: bestille-en-kjoring.md (what the commissioner gets) + ekspert-svar.md (what
the expert's queue looks like, and that "rejected" is the validator's verdict on
the numbers, never a professional judgement of the idea).

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

docs/bestille-en-kjoring.md

@@ -120,6 +120,26 @@ alternativer — ikke besparelser som legges oppå hverandre. Derfor står det *
 og *hvilken kjøringen bærer videre*, aldri en sum. (Dette ble oppdaget ved å faktisk kjøre den:
 tre tilnærminger mot samme linje ga «totalt 90 000», som ingen av dem kunne innfri.)
 
+## Hver tilnærming kan dømmes for seg
+
+Kjører du med `--outbox-dir` (og `--run-id`), legger kjøringen igjen **én artefakt per vurdert
+tilnærming** — `run-001-led-retrofit-proposal.json`, `run-001-driftsavtale-proposal.json`, og så
+videre — ikke bare for den kjøringen bar videre.
+
+Det er ikke en bokføringsdetalj. Uten det kunne bare den valgte tilnærmingen få en fagdom, og de
+andre du bestilte ville aldri nådd læringssløyfa: de ble vurdert, rapportert i oppgjøret, og deretter
+glemt. Nå står de hver for seg i køen din:
+
+```
+uv run python -m portfolio_optimiser.hitl pending --outbox-dir utboks --verdict-dir innboks
+run-001 c91cb2fe1aa139a9 validated [led-retrofit]
+run-001 4f0a1d77b2e5c318 rejected [driftsavtale]
+```
+
+Hvordan du svarer på dem står i [ekspert-svar.md](ekspert-svar.md). En tilnærming med status
+NOT EVALUATED har ingen artefakt — kjøringen produserte aldri et forslag for den, så det er ingenting
+å dømme.
+
 ## Hva bestillingen ikke gjør
 
 - **Den overstyrer ikke validatoren.** Se ærlighetsmerkingen øverst.

docs/ekspert-svar.md

@@ -67,6 +67,27 @@ din, så den må gjengis **ordrett**. Resten av feltene ligger i `utboks/run-001
 `measure` → `measure_type`, hver `affected_items[].code` → `affected_codes`, og
 `claimed_saving_nok` uendret.
 
+### Har du bestilt flere tilnærminger?
+
+Da får **hver vurderte tilnærming sin egen artefakt** — ellers kunne du bare dømt den ene kjøringen
+valgte, og de andre du bestilte ville ikke lært systemet noe. Filene heter
+`utboks/run-001-<tilnærming>-proposal.json`, og `pending` lister dem hver for seg med
+tilnærmingen i klammer:
+
+```
+run-001 c91cb2fe1aa139a9 validated [behovsstyrt-lys]
+run-001 4f0a1d77b2e5c318 rejected [aggregat-bytte]
+run-001 9b31e0c4a7d6f025 validated [own-proposal]
+```
+
+`own-proposal` er systemets eget forslag, ikke et av dine. Hver linje dømmes for seg, med sin egen
+`id` — akkurat som over. To tilnærminger som endte på nøyaktig samme forslag deler `id` (den er en
+innholds-hash), og da gjør én dom opp for begge; det er ikke en feil, det er at de var samme forslag.
+
+**Merk hva artefaktene *ikke* sier:** en tilnærming som står som `rejected`, er avvist av den
+deterministiske validatoren — altså på tallene. Det er ikke en fagdom over ideen. Det er nettopp
+derfor den fortsatt havner i `pending` og venter på deg.
+
 **Utboks og innboks skal være to forskjellige mapper.** De har motsatt eierskap: systemet skriver
 utboksen, du skriver innboksen. (Målt: å peke dem på samme mappe ødelegger ingenting i dag —
 utboksens filer heter `run-001-*.json` og mangler dom-feltene, så innboks-lasteren hopper over dem.