feat(versiebeheer): per-assessment pin-kolom (Fase 2b)

[robbertbos]

Fase 2b — per-assessment pin-kolom (de kern)

Legt de per-assessment versie-pin vast: een oud assessment kan straks op zijn versie blijven terwijl je aan een nieuwere werkt.

Wat

• Nieuwe kolom definitionVersion (text, nullable) op assessment_instances — de precieze gepinde versie (3.0, 3.1.0-concept.2), los van currentVersion (de per-save checkpointteller).
• Migratie 0004_polite_may_parker.sql: enkel ALTER TABLE ... ADD COLUMN — additief, geen DROP+CREATE, geen "public".-prefix (handmatig geverifieerd, CLAUDE.md-valkuil).
• Create-flow: pinnedVersion = body.definitionVersion ?? DEFAULT_DEFINITION_VERSIONS[type], autoritatief op de rij opgeslagen.
• normalizeCreateState stelt metadata.urn samen uit de pin (D1: een concept-pin → precieze urn).
• Pin meegenomen in de assessmentAccess-projectie + het api.ts AssessmentInstance-type.

Voorbeeld (bewijs uit de integratietests)

POST .../assessments { assessmentType: 'dpia' }
  -> definitionVersion: '3.0'                       (type-default)

POST .../assessments { assessmentType: 'dpia', definitionVersion: '3.1.0-concept.2', state: {...} }
  -> definitionVersion: '3.1.0-concept.2'
  -> cachedState.metadata.urn: 'urn:nl:dpia:3.1.0-concept.2'   (D1: concept precies)

Gemaakte keuzes (toelichting voor jouw review)

• Nullable, geen risicovolle backfill-DML. Pre-pin-rijen krijgen NULL; consumenten vallen bij lezen terug op de versie in cachedState.metadata.urn (de feitelijke invul-versie — niet stil "latest"). → Akkoord, of wil je toch een expliciete 3-staps-backfill naar oudste-officieel? Ik heb het uitgesteld omdat met één bestaande officiële versie de read-fallback exact equivalent is én testbaar blijft (geen ongeteste data-DML in deze PR).
• Default = latest-official ({dpia:'3.0', prescan:'2.0', iama:'2.0'}, naast de bestaande ASSESSMENT_TYPE_URNS).
• Server-autoritatieve coercion van een client-urn nog niet — de kolom is de bron voor straks resolve-by-pin; coercion + mismatch-logging is bewust een vervolgstap (plan E).
• Geen core-dep in de backend: de urn-compositie (urn:nl:<type>:<versie>) is triviaal en klopt voor MAJOR.MINOR-officieel én concept; geen gedeelde helper (aanname: officiële versies blijven MAJOR.MINOR).

Aandachtspunten

• Migratie draait idempotent in de tests (setup.ts) tegen Postgres; alle 430 backend-tests groen @ 100% coverage.
• resolve-by-pin (frontend laadt de gepinde versie via de feat(versiebeheer): versie-bewuste schemaStore (Fase 2a) #408-registry) volgt als aparte PR — déze PR registreert de pin, consumeert hem nog niet bij het laden.

Stapelt op #409 (D1) → #408 (loader) → feat.