Make StemDeck usable from another device

[thcp]

Eight problems, one per commit. They ship together because the first five are the same story told from different angles: opening StemDeck from a phone should give you the whole app, not a viewer.

Closes #560
Closes #561
Closes #562
Closes #563
Closes #564
Closes #565
Closes #566
Closes #567

The main thread

Transpose only worked on the host machine. It is an AudioWorklet, which browsers grant only to a secure context, so a phone on http://192.168.x.x got working playback and a key control that silently did nothing.

The ScriptProcessorNode fallback that would have avoided TLS was measured and rejected. A bare passthrough with no DSP in it loses audio at every buffer size (1024 drops 17.8% of windows, 4096 drops 5.4%, 16384 drops 1.0%, never zero). That trades a control that does nothing for one that produces broken audio.

So the secure context is made real instead of worked around:

• The desktop app generates its own certificate on the user's machine, into <data>/certs/, with the machine's real LAN IPs as SANs. Nothing is shipped: a certificate in the release would publish its private key to everyone who downloaded it, which is worse than plain http because it looks secure. It regenerates when the addresses change or expiry nears, and lasts 397 days because Safari rejects anything over 398.
• A second uvicorn listener on 8443 serves the LAN over TLS, against the same app object, so there is one registry, one queue and one Demucs worker. lifespan="off" on it, or the first server to stop would reap the worker out from under the other. Plain http stays on loopback for the Tauri webview, which has no chrome to click a certificate interstitial through and loses nothing, because loopback is already a secure context.
• Server mode refuses a plaintext non-local origin with a 403 that explains itself and names three ways out. X-Forwarded-Proto and RFC 7239 Forwarded are honoured, so the common self-hosted shape (SWAG, NPM, Traefik, Caddy in front, plain http upstream) is served normally. The host machine is always served, so this can never lock someone out of their own server.

uv.lock is untouched, deliberately. uvicorn's TLS is stdlib ssl and the generator is Rust, so runtimeId does not move and the desktop in-app updater still offers this release to existing installs.

The rest of making the phone work

• Compression. Opening the phone UI pulled 456 KB of uncompressed text, of which i18n.js alone is 328 KB. Measured on the LAN: 334 KB to 88 KB. TLS was ruled out first as the cause (200 MB/s against 171 MB/s bulk, 48 ms against 55 ms per range request). The middleware is 200-only and allowlisted by content type, because compressing a 206 range window of audio rewrites Content-Length while Content-Range still describes the uncompressed bytes, which would have broken phone playback outright.
• Trash moved to the server. There were two answers to "what is in my library": the desktop's per-device storage and the phone's GET /api/jobs. Deleting on the desktop left the job in the registry, so the phone kept listing tracks the user thought they had binned. Trashing is not deleting: stems stay on disk, so a mistaken tap on a phone never destroys audio.
• A key control on the phone at all. It has three states, not two, and the third is the common one: available, not yet loaded, and impossible on this origin. A dead stepper is indistinguishable from a broken build, so it is visibly disabled and says why.
• Settings tabs scroll. Only General did, which was a bet that no other tab would outgrow 540px. Network did, and a pane with no overflow does not clip, it runs on underneath: the Done button ended up drawn on top of the Port setting.

Riders

• yt-dlp extractors. 939 of them shipped to every user's disk, a large number for pornography sites, none reachable because StemDeck rejects every host but YouTube and SoundCloud before yt-dlp is called. 930 removed. The keep set is discovered rather than hand-written, because extractors import each other across the package, and every packaging path fails the build if the pruned tree does not import or if YouTube and SoundCloud stop matching.
• We Recommend. Three people added, one recategorised, a new Writers category, the full no-money disclaimer moved into the dialog, alphabetical order resolved per language, and a wider dialog with a measured column split so the list stops outgrowing it.
• The Linux installer exec-bit test failed on every Windows checkout, because NTFS has no execute bit. It was also asking the wrong question: the tarball is built from what git records, not from the developer's working copy.

Verification

pytest (Linux, via WSL)	992 passed, 0 failed
pytest (Windows)	944 passed, 13 pre-existing environment failures
Playwright	109 passed
ruff check / format	clean
cargo clippy / fmt	clean
cargo test certs	7 passed

The 13 Windows failures are ffmpeg not being on PATH for a from-source run, Linux-only packaging cases, and process-timing tests. All pass on Linux. None are touched by this branch.

Also verified by hand on a real phone over the LAN: certificate accepted once, transpose working, and the compression measured on the wire.

Before merging

The Unraid template pin in templates/stemdeck.xml is deliberately untouched. Per the project's rule it tracks the latest published pre-release, so it should be bumped after a release is published with all its assets, not at merge time.

[thcp]

Went through the five bot comments. Three applied, two declined.

Applied: mixed import styles (3 comments)

eb82fce. Both test files reached for app.main two ways -- import app.main as main for monkeypatching, from app.main import app for the ASGI instance.

Worth doing not just to quiet the rule: from X import Y binds the object at import time, so a later monkeypatch of main.app would be invisible through the second name and the test would quietly exercise the unpatched object. Nothing patches app itself today (only _secure_origin_required, _local_ips, SSL_CERTFILE, SSL_KEYFILE), so it was a latent trap rather than a live bug. main.app is the same object; behaviour is unchanged.

Declined: "unused global variable" on app/core/tls_listener.py:128 (2 comments)

These are false positives, and acting on them would be a regression.

_server and _task are written in start() and read in stop():

# start(), line 118
_server, _task, _active_port = server, task, port

# stop(), lines 127-128
server, task = _server, _task     # read here
_server = _task = None            # the line flagged as unused

The flagged assignment is what makes stop() idempotent. On a second call, server, task = _server, _task reads those Nones and takes the early return two lines later. test_stopping_one_that_never_started_is_harmless covers exactly that path.

The analysis appears to be statement-local: at line 128 the assigned value is not read before being reassigned within that function, which is true and irrelevant -- the read happens on the next invocation. Deleting the line, or renaming to _unused, would leave a stopped listener holding a dead server object and make a second stop() try to shut it down again.

Leaving both as they are.

Verification

ruff check     All checks passed
ruff format    already formatted
pytest         990 passed, 2 failed, 3 skipped

The 2 failures are test_stems_api.py::test_all_stems_zip_ogg and ::test_ogg_is_still_streamed, which fail identically on main -- a local ffmpeg without libvorbis, most likely. Unrelated to this branch.