Let the user put a panel away, and make the lanes actually fit

[thcp]

Four problems around the mixer, found by pulling on one thread: #480 asked for a
way to reduce the panels around it, and building that exposed three defects the
panels had been hiding.

Addresses #480, which stays open: this is a way to reclaim the space, not a
decision about what the studio shows on first open, and collapsing is all or
nothing per panel where the report asked for one row of it.

Closes #497
Closes #498
Closes #499

Put a panel away when you are not using it (#480, partial)

#480 was not asking for smaller panels. Its reporter said so directly:

every one of those panels shows something useful [...] The issue is that they
are all mandatory at all times. I do not need the presence percentages while I
am setting fader levels, and I do not need the waveform while I am reading the
analysis. Right now the app has no way to say that.

So this is a way to say it. Three toggles collapse the analysis header, the
sections bar and the footer timeline, each handing its height to the mixer:

	Mixer	Lanes visible	Scrolls?
Default	370 px	5 of 6	yes
Analysis off	443 px	6 of 6	no
All three off	573 px	6 of 6	no

One click on Analysis is enough. Together they are worth 202 px.

They collapse to nothing rather than to a stub, which is only possible because
the controls live somewhere else: a stub tall enough to hold its own control
costs most of what collapsing the smaller panels returns. So all three sit in one
row under the composer, sharing the right edge and the exact width of the two
controls above them, from the same --composer-action-w those are sized from.
The topbar does not grow to hold it: it already carried 27 px of slack around a
50 px composer.

Legible means the panel is there, struck through means it is put away. The other
way round inverts what a pressed toggle looks like everywhere else, and makes the
default state the loud one.

This does not decide what the studio shows on first open. Every panel is
still there by default. Whether that default is right is a separate question.

Lanes never fitted the panel (#497)

Found by collapsing a panel and watching the space go nowhere. The lanes were
sized once, at track load, and never again.

Window resizing already showed it, with no toggles involved: on a 1366x768
window the panel is 370 px and each lane 72 px; drag the window to 1200 px tall
and the panel becomes 802 px while the lanes stay at 72. 432 px unused. The
bigger the display, the more of it the waveforms refused to occupy.

Three things had to change for the lanes to follow: the fit runs again from an
observer on the wave panel, .waves-column takes a floor from the stack height
rather than the multitrack's frozen lane height, and the maths allows for the
2 px separators it had been ignoring.

A name and its waveform drifted apart (#498)

The mixer strip and the waveform lanes are two columns of the same rows, and
nothing made them agree. At 1600x768 after a resize from 900: mixer rows 72 px
apart, waveform rows 83 px apart, the last pair 55 px out of line. By the
last stem the label was most of a row from the waveform it names.

They were built from different numbers. The mixer stack is count * --lane-h,
recomputed from the panel; the waveform column took its height from the
multitrack, whose lane height is fixed when its tracks are created. The computed
stack said 432 px and the column was still 498.

Two smaller errors in the same place, both pushing the same way: every mixer row
draws a 2 px bottom border while the stack counted count - 1 separators, and
the stem name sat 7 px above the row's centre because it and its meter are
centred as a pair while the waveform is centred on the line itself.

Zero row drift now across twelve window heights from 720 to 1300, including the
range where lanes overflow rather than fit, which is where the 55 px came from.

Song structure was a preference (#499)

Switched on once it stayed on: for that import, for every import after it, and
for every session until someone remembered. Stored server-side, so it survived a
restart and applied to anyone else pointed at the same StemDeck. The pass costs
minutes of CPU per import.

It is off at startup now, and off again as soon as the studio loads a song. The
button and the setting move together, because the setting is what the runner
reads.

That alone would have introduced a worse bug than it fixed. The runner read
the setting when it reached the sections stage, the last thing the pipeline does,
and a comment said that was deliberate. Correct for a preference, wrong for a
per-import choice: a user who switched it on, started an import and browsed to
another track while waiting would have lost the pass they asked and waited for.
Silently, with no sections and no explanation.

So the decision moved to the moment the user makes it. The job carries the flag,
captured at creation, at all three places a job is created -- URL submit, file
upload, and playlist import, where one read covers the batch.

Verification

83 browser tests pass, five of them new. Backend 845 pass; the 14 failures are
pre-existing and reproduce on main, nine of them because this machine has no
ffmpeg.

Every new guarantee was checked against a build with the fix removed: the three
alignment tests, and both toggle tests.

i18n complete at 474 keys across all nine tables. ruff check, ruff format --check and node --check clean.

Before merging

• uv.lock untouched, so the desktop in-app updater is unaffected.
• The Unraid template pin stays at 0.15.2: it moves after a release is
  published with all its assets, not at merge time.