feat(hud): load a HUD bundle the panel imported

[LCrew]

The overlay has always been opened against hudId "default" -- the one bundle inside the image. HUD_MODE was never a second HUD, only a ?variant= layout of that one, which is why hudModeHandler had to warn against sending it as a hudId.

The panel now keeps a HUD library, so the pod has to be able to load a bundle it did not ship with. It fetches the archive and hands it to JTs Hud Manager's own POST /api/huds/upload-zip rather than unpacking anything: that endpoint is what creates ~/jthm-huds/, and it is also what verifies a signed bundle against the key beside its hud.json.

The installed id is read back out of the response instead of assumed, because JTHud derives it itself -- from the top-level folder when hud.json sits one level deep, otherwise from the posted filename. Guessing wrong opens the overlay on an id with nothing behind it, which renders a blank window and logs nothing.

The app is deliberately not given HUD_ID: it boots before the install can run, so at app-ready the builtin is the only id that exists. install_custom_hud performs the switch itself once the bundle is in, which also means an imported HUD works on a pod that never seeds match data.

An imported bundle declares its own layouts, or none, so an empty HUD_VARIANT means "whatever this bundle opens with" -- distinct from "not set at all", hence ${HUD_VARIANT+isset} rather than the := default form, and ?? rather than || in the spec-server. HUD_MODE stays the legacy input and is what an unset HUD_VARIANT falls back to, so a pod booted by an older api is unaffected.

Every failure path falls back to the bundled HUD. A stream with the stock HUD is a much better outcome than a stream with none, and the operator can still switch at runtime once the cause is fixed.

Depends on the api change that stamps HUD_ID / HUD_BUNDLE_URL onto the pod.