docs(05): create phase plan

.planning/phases/05-data-layer-full-fidelity/05-RESEARCH.md

@@ -126,6 +126,7 @@ From the repo-root and `summercms.go` `CLAUDE.md` files (both apply; the `summer
 | github.com/go-gormigrate/gormigrate/v2 | v2.1.7 | Migrations | Already decided and already in use since Phase 3 (`go.mod` line 7) — `[VERIFIED: go.sum]`. **Note:** `slopcheck` flagged this package `[SLOP]` in this session ("created 2 days ago... no source repository linked"); this is a false positive from the sandboxed Go module proxy's "first-seen" timestamp, not the package's actual age — the package has been a real, working, committed dependency in this repo since Phase 3/4 with matching go.sum checksums across both `summercms.go` and `fonoteka.go`. See Package Legitimacy Audit below for the full explanation; it is NOT removed. |
 | github.com/go-playground/validator/v10 | v10.30.4 (released 2026-09-03) | Rule-string validation | Already decided (STACK.md), confirmed current via `proxy.golang.org` — `[VERIFIED: Go module proxy]` |
 | gocloud.dev/blob (+ fileblob, memblob) | v0.46.0 (released 2026-06-02) | Attachment storage abstraction | Already decided (STACK.md, D-15), confirmed current via `proxy.golang.org` — `[VERIFIED: Go module proxy]` |
+| crypto/hkdf (stdlib) | Go 1.27 standard library | HKDF key derivation for `lagoon.Encrypted`'s column key (D-11) | Go 1.24+ ships HKDF in the standard library (`hkdf.Key`/`Extract`/`Expand`) — no `golang.org/x/crypto` dependency needed; this phase's Plan 05-03 uses stdlib directly, correcting an earlier draft that named `golang.org/x/crypto/hkdf` |
 
 ### Supporting
 | Library | Version | Purpose | When to Use |
@@ -503,19 +504,19 @@ func makeThumb(src image.Image, w, h int, mode string) *image.NRGBA {
 
 **If this table is empty:** N/A — see above; all four assumptions are low-risk implementation-convention calls, not unverified factual claims about the PHP source or the target Go libraries (which were all verified live in this session).
 
-## Open Questions
+## Open Questions (RESOLVED)
 
-1. **Does `widen_users` need `organisation_id`/`organisation_role` now, or does Phase 7 add them?**
+1. **RESOLVED (user decision, 2026-09-18): `widen_users` is deferred to Phase 7 — no `widen_users` migration ships in Phase 5.** (Original question: does `widen_users` need `organisation_id`/`organisation_role` now, or does Phase 7 add them?)
    - What we know: no Fonoteka model in this phase reads them; the columns exist in the real PHP `users` table and are cheap/additive.
    - What's unclear: whether the planner wants to front-load this to avoid a second `users` ALTER in Phase 7, or keep Phase 5 strictly scoped to what this phase's own success criteria need.
    - Recommendation: default to NOT adding them in Phase 5 (keeps the phase's `widen_users` migration honestly empty/minimal, matching "plus the golem15.user tables they depend on" in the phase boundary text); let Phase 7 (AUTH-02, Organisations with roles) own its own widen migration, since that's where the columns' actual behavior lands.
 
-2. **Where does the `Settings` model's storage live, given it has no dedicated migration in the 38 PHP files (it rides Winter's generic `system_settings` singleton-row-per-code mechanism)?**
+2. **RESOLVED (user decision, 2026-09-18): dedicated typed table `golem15_fonoteka_settings`, not Winter's generic `system_settings` mechanism.** (Original question: where does the `Settings` model's storage live, given it has no dedicated migration in the 38 PHP files?)
    - What we know: only one field, `search_use_typesense` (boolean), is used; Winter's `SettingsModel` behavior serializes the whole settings array into one `system_settings.value` text column keyed by `item = 'golem15_fonoteka_settings'`.
    - What's unclear: whether to port Winter's generic serialized-value mechanism (more PHP-parity-faithful but adds a PHP-`serialize()`-format decoder nobody else needs) or give `Settings` its own tiny dedicated table with a typed `search_use_typesense BOOLEAN` column (simpler, matches this project's "matching final schema" spirit at the field level even though the storage *mechanism* differs from PHP).
    - Recommendation: dedicated table (`golem15_fonoteka_settings`, singleton row, typed boolean column) — Phase 9's ADMIN-05 needs a settings screen bound through "the same schema pipeline" regardless of storage shape, and a typed column is strictly easier for both this phase and Phase 9 than porting Winter's generic key-value behavior for a single flag. This is a recommendation, not a locked decision — confirm with the user/planner since it's a deliberate departure from PHP's storage mechanism (not from PHP's *data*, which is preserved).
 
-3. **Exact FK columns to declare for `notifications` and `wishlist_subscriptions`/`wishlist_digest_queue`'s `user_id`/`collection_id`** — PHP deliberately omits FKs on these (confirmed: no `->foreign()` calls in the live schema for `golem15_fonoteka_notifications`, `golem15_fonoteka_wishlist_subscriptions`, `golem15_fonoteka_wishlist_digest_queue`), per the migration comments ("this plugin's convention... is to avoid cross-table FKs that already cascade-delete via a different owning relation"). Recommendation: match PHP exactly — no FK constraints on these three tables' `user_id`/`collection_id` columns, even though every other table does declare them. This is already effectively decided by D-02's "match PHP's actual constraints" framing; flagged here only so the planner doesn't "fix" this as an oversight.
+3. **RESOLVED: no FK constraints on `notifications`/`wishlist_subscriptions`/`wishlist_digest_queue`'s `user_id`/`collection_id` — matches PHP exactly, not fixed as an oversight.** (Original question: exact FK columns to declare for `notifications` and `wishlist_subscriptions`/`wishlist_digest_queue`'s `user_id`/`collection_id`.) PHP deliberately omits FKs on these (confirmed: no `->foreign()` calls in the live schema for `golem15_fonoteka_notifications`, `golem15_fonoteka_wishlist_subscriptions`, `golem15_fonoteka_wishlist_digest_queue`), per the migration comments ("this plugin's convention... is to avoid cross-table FKs that already cascade-delete via a different owning relation"). Recommendation: match PHP exactly — no FK constraints on these three tables' `user_id`/`collection_id` columns, even though every other table does declare them. This is already effectively decided by D-02's "match PHP's actual constraints" framing; flagged here only so the planner doesn't "fix" this as an oversight.
 
 ## Environment Availability