docs(backlog): record portal_token schema deviation from RFC v0.2 §5.3

Schema reality (varchar(64), accommodating SHA-256 hex digest) diverges
from RFC v0.2 §5.3 ("ULID unique nullable"). Session 1 implementation is
correct; RFC needs amendment in next legitimate cycle. Tracked under
RFC-TIMETABLE-V0.2-PORTAL-TOKEN-SCHEMA-AMEND. Distinct from
RFC-TIMETABLE-V0.2-DOC-CLEANUP (which covers stale cross-references).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

dev-docs/BACKLOG.md

@@ -704,6 +704,27 @@ voor implementatie van Sessions 2–6.
 
 ---
 
+### RFC-TIMETABLE-V0.2-PORTAL-TOKEN-SCHEMA-AMEND — `portal_token` is varchar(64), niet ULID
+
+**Aanleiding:** RFC v0.2 §5.3 specificeert `artist_engagements.portal_token`
+als `ULID unique nullable`. Session 1 implementatie heeft de kolom verbreed
+naar `varchar(64)` omdat `PortalTokenController` `hash('sha256', $plainToken)`
+opslaat (64-char hex digest); `char(26)` zou stilzwijgend truncaten onder
+MySQL strict mode. De implementatie is correct — schema reality is de bron
+van waarheid — maar de RFC-annotatie is stale.
+
+**Wat:** Bij de eerstvolgende RFC amendement-cyclus, hetzij een v0.3
+uitbrengen met §5.3 spec gecorrigeerd, hetzij een §5.3 footnote toevoegen
+aan v0.2. Approved RFCs worden niet ad-hoc gepatched; dit ticket vangt
+de divergentie totdat een legitieme amendement langskomt.
+
+**Reference:** Session 1 commits `eb6d396` (column widening) en `64878f2`
+(controller wired through `artist_engagements.portal_token`).
+
+**Prioriteit:** Laag — pure doc-spec alignment; code is correct.
+
+---
+
 ### TECH-01 — Bestaande tests bijwerken na festival/event refactor
 
 **Aanleiding:** Na toevoegen parent_event_id worden bestaande tests