Decouple practice item from a single track (allow a track pool)

[sjiang1]

As a teacher, I want students to be able to pick one of the tracks to practice each day, so that the student can practice various tracks over time and the practice doesn't get too long every day.

Current Implementation

Today a practice item is welded to exactly one track. From src/app/plans.ts:

export type PracticeItem = {
  trackId: string;        // one track, always
  tasks: PlanTask[];
  dice: boolean;
  teacherNote?: string;
};

So "practice item = one track + its tasks." A Track (audio / video / reference) is just the thing being practiced. To support upcoming features — most immediately a die that picks one of several tracks (see the dice issue) — a practice item needs to reference a pool of tracks, with its tasks applying to whichever track is active.

This issue is the decoupling only — no roll UI. It makes the data model and editor able to hold more than one track per item.

Scope

• PracticeItem references a pool of tracks instead of one. Remove trackId so the model stays clear and simple to maintain. Every item carries trackChoices (one track for a normal item, several for a pool):

  export type PracticeItem = {
    trackChoices: string[];   // pool of trackIds (one or more); replaces trackId
    tasks: PlanTask[];        // tasks apply to whichever track is active
    dice: boolean;
    teacherNote?: string;
  };

• PlanEditor (src/app/plans/PlanEditor.tsx): add/remove tracks in a pool for an item.
• Rendering (src/app/PracticeTasksList.tsx): handle an item that has multiple tracks (the picking mechanism comes in the dice issue; for now a simple list / first-track render is fine).
• Migration: rewrite existing practice items in data/plans.json — wrap each trackId: "x" into trackChoices: ["x"].

Out of scope

• The die / roll UI and per-face customization — separate issue.

Notes

• Keep the Track vs Practice item distinction clean: Track = the audio/reference piece; Practice item = the plan entry that references track(s) + tasks/notes.

[sjiang1]

Implemented in #6 with the agreed scope: editor still creates/swaps single-element pools (no new pool-editing UI). The multi-track pool-editing UI moved to #5, where it pairs with the roll. The data model, prod-Redis read-time migration, and all consumers now go through a single primaryTrackId(item) seam that #5 will swap for the rolled track.