docs: resolve 3 Phase 9 open questions from Daniel

Genre browse stays route-reachable (deprioritized, not retired).
Session/Mix single-track is a hard upload constraint.
/albums redirects to /cuts when CUTS lands.

PLAN.md

@@ -223,9 +223,9 @@ A new `api/release` controller — the medium unit is the *release*, not the tra
   - **Acceptance criteria:** Mix browser lists only Mix releases and shows per-row waveform status; uploading a Mix generates + stores a high-res waveform; the per-row Generate action recovers a missing waveform.
 - **Prerequisite:** 9.2.
 - **Open questions:**
-  - **Genre browse fate.** Renaming the Genre tab to Release Archive takes its slot. Recommend keeping `CmsGenreBrowser` route-reachable but tab-less (it's built and works), not retiring genre browse wholesale. Confirm with Daniel.
+  - **Genre browse fate.** Resolved: the Genre tab slot is taken by Release Archive (Wave 3A as specced); the existing genre browse functionality is deprioritized and stays route-reachable as-is — no active development, no retirement. The team should not remove it.
   - **Waveform preprocessor reuse.** Is the existing preprocessor factored to accept a resolution parameter, or does 9.3.C include a refactor to share one pipeline across player-bar and Mix? Recommend one parameterized pipeline.
-  - **Single-track invariant.** Is "single track per Session/Mix" a hard upload constraint (drop the multi-track master list for those media) or a convention? Recommend enforce — it simplifies both form and detail view.
+  - **Single-track invariant.** Resolved: hard constraint. One track per Session/Mix release is enforced at upload — the CMS form for those media drops the multi-track master list entirely.
 
 ---
 
@@ -241,7 +241,7 @@ A new `api/release` controller — the medium unit is the *release*, not the tra
   - **Why:** Honour the existing studio-release browse under the new medium taxonomy. Lowest-effort of the three media.
   - **Shape:** Parameterize `AlbumsView`'s data load with a medium filter rather than forking a component. `/cuts` = `AlbumsView` with `Medium == Cut`.
   - **Acceptance criteria:** `/cuts` shows only `Cut` releases with the current AlbumsView ergonomics.
-  - **Open question:** Does the current Releases/`AlbumsView` route redirect to `/cuts` or stay an all-media view? Small routing call.
+  - **Resolved:** When `/cuts` lands, the existing `/albums` route issues a redirect to `/cuts`. Old URLs keep working; no hard 404.
 - **9.4.C — SESSIONS (`/sessions` + `/sessions/{id}`).**
   - **What:** Gallery of session cards (cover, session name, artist) at `/sessions`; detail at `/sessions/{id}` mirroring `TrackDetail` but with the **hero image dominant above the fold**, cover secondary.
   - **Why:** Sessions are an authored content kind the home page advertises; the hero image is their distinctive visual.

product-notes/phase-9-release-medium-types.md

@@ -426,26 +426,20 @@ above-the-fold without polluting the others.
 
 1. **Waveform storage shape (§2.3).** Vault blob + `WaveformEntryKey` (recommended) vs. JSON column
    on `MixMetadata`. Determines whether Wave 1 touches the vault abstraction. *Recommend vault blob.*
-2. **Genre browse fate (§3.1).** "Rename the Genre tab to Release Archive" takes the third tab's
-   slot. Does genre browsing survive (route-reachable but tab-less — recommended), move under the
-   Cut browser as a secondary filter, or retire in the CMS? *Recommend keep route-reachable.*
+2. **Resolved: Genre browse fate (§3.1).** Daniel's decision: the Genre tab slot is taken by Release Archive (Wave 3A as specced); the existing genre browse functionality is deprioritized and stays route-reachable as-is — no active development, no retirement. The team should not remove it.
 3. **Waveform preprocessor reuse (§3.4).** Is the existing player-bar waveform preprocessor factored
    to accept a resolution parameter, or does Wave 3 track C include a refactor to share one pipeline
    across player-bar (low-res) and Mix (high-res)? *Recommend one parameterized pipeline.*
 4. **Detail-page strategy (§5.3).** Three separate detail pages vs. one branching `TrackDetail` vs.
    shared `ReleaseDetailScaffold` + per-medium hero slot (recommended). Sets the public-site Wave 4
    shape. *Recommend the scaffold.*
-5. **Old releases route (§5.2).** Does the current Releases/`AlbumsView` route redirect to `/cuts`,
-   or stay as an all-media view? *Small routing call.*
+5. **Resolved: Old `/albums` route fate (§5.2).** Daniel's decision: when `/cuts` lands, the existing `/albums` route issues a redirect to `/cuts`. Old URLs keep working; no hard 404.
 6. **Nav model children (§5.1).** Extend `MenuPages` with an optional `Children` collection
    (recommended, generalizes) vs. hardcode ARCHIVE as a bespoke popover component. *Recommend the
    model extension.*
 7. **`MixWaveformVisualizer` seek-on-click (§5.4).** Design the position-binding seam now even if
    click-to-seek ships later? *Recommend design the seam, defer the feature.*
-8. **Single-track invariant for Session/Mix (§3.3).** Sessions and Mixes are "single-track." Is that
-   a hard constraint enforced at upload (one track per Session/Mix release), or a convention? If
-   hard, the CMS upload form for those media should drop the multi-track master list entirely.
-   *Recommend enforce — it simplifies both the form and the detail view.*
+8. **Resolved: Single-track invariant for Session/Mix (§3.3).** Daniel's decision: hard constraint. One track per Session/Mix release is enforced at upload — the CMS form for those media drops the multi-track master list entirely.
 
 ---