docs(board): tracks.json is on v4, and two parsers disagree on what a track is

The regen moved timecodes by up to 21s (Piment +21.0, REVOLUTION +19.0, Gimme
Acid +16.7). That file is not just website furniture — Slopmotion cuts visuals
to it, so the release videos were pointed a third of a minute off the music on
a third of the record.

The more interesting finding is a parser conflict the regen walked into.
build_gig_tracksjson.py drafts NEW gig pages and never computes the
styleDistribution that LiveEvent.js renders; gig-metadata.py regenerates
existing ones and does. They also disagree outright on REVOLUTION's style
(jazz vs nujazz). Two parsers, one concept — so the board's line that
build_gig_tracksjson 'is now the way to make any gig page' is too strong and
is corrected here rather than left to bite the next regen.

Left explicitly to PLN: whether the OPAL page documents the set as PERFORMED
(15 tracks, Desire included) or as RELEASED (14). Desire has no v4 boundary
because it was cut, so its v3 timecode rides through unverified. A page can
honestly be either thing; only he knows which one he wants a visitor to get.

TASKS_DUMP.md

@@ -1713,3 +1713,36 @@ duration check in August. The lens runs at ±0.05 s.
    cuts we are about to delete.
 4. Then OPAL's `audio:` field in `www/content/lives/2026/opal-festival-2026.md`
    can finally be filled, and the catalog's release links behind it.
+
+### ✅ www OPAL `tracks.json` regenerated from v4 (`5654047` on www `main`, pushed)
+
+Drift was up to **21 s** (Piment Brésilien +21.0, REVOLUTION +19.0, Gimme Acid
++16.7, Take Five +10.0, You My Sunshine −9.3); `totalDuration_s` 4769.1 → 4726.06.
+Slopmotion reads this file to cut visuals to the set, so release videos would
+have been that far off the music on a third of the record.
+
+Verified as a real diff, not an assurance: name/order/style/bpm/section/venue/
+stage/title/date and the `bpmRange`/`styleDistribution`/`samplePacks` aggregates
+are byte-identical old vs new. One legitimate non-timing change kept: Ghosts in
+the Toilets lost sample `"e"`, traced to `b5ad8b6` commenting out a note-pattern
+line that `setlist_samples.py` had been mis-reading as a sample token — the new
+parse is the correct one.
+
+🔴 **NEW: two parsers disagree about what a gig track IS** (`feedback_one_parser_per_concept`).
+`tools/gig-metadata.py` and `armada/tide-table/build_gig_tracksjson.py` are not
+interchangeable, and the board's claim that the latter "is now the way to make any
+gig page" is too strong:
+- `build_gig_tracksjson.py` is for **drafting a brand-new** page (emits `_draft`/
+  `_needs_pln`/`_provenance`, wants a spec + `--meta` sidecar). It never computes
+  the top-level `styleDistribution` field that `LiveEvent.js` actually renders.
+- Its `style_of()` labels REVOLUTION's path `"jazz"`; `gig-metadata.py`'s
+  `STYLE_BY_PATH` says `"nujazz"`.
+Decide which one owns the concept and make the other call it. Until then, use
+`tools/gig-metadata.py --only-played` for a **regen** of an existing gig.
+
+❓ **Open decision for PLN — Desire (track 14) on the OPAL gig page.** It has no
+boundary in `segments_v4.json` because it was cut from the release, so its old v3
+timecode is carried through unchanged rather than guessed at or dropped. The page
+currently documents the set **as performed** (15 tracks). Should it stay that way,
+or drop to the 14 released tracks so the page matches what a visitor can actually
+go and listen to? Not a machine call.