feat(umbrel): add headless seeder daemon, Axum web server, and Umbrel packaging

[borocode]

Summary

This PR adds support for running Napstr as a 24/7 headless sovereign audio seeder and web player for Umbrel / UmbrelOS (and any headless server/docker environment).

Key Additions

1. Headless Daemon (napstr-daemon):

   • Lightweight binary running an Axum REST + WebSocket server on port 30421.
   • Auto-manages the Tor onion controller and Nostr relay connections.
   • Watches and indexes local music libraries (/music) without needing a desktop window open.

2. Universal Dual-Mode Client:

   • Added $lib/api.ts bridge that automatically detects whether Napstr is running in desktop Tauri or inside a web browser.
   • Added in-browser HTML5 WebAudio streaming engine ($lib/webAudio.ts) with HTTP Range request (206 Partial Content) support.

3. Decoupled Event Layer:

   • EventEmitter trait implemented for both Tauri IPC (TauriEmitter) and Tokio broadcast channels (BroadcasterEmitter).

4. Umbrel App Store Packaging:

   • umbrel-app.yml manifest, docker-compose.yml, and multi-stage Dockerfile.umbrel.

Verification

• npm run build passes with 0 errors (static Svelte 5 SPA).
• cargo build --bin napstr-daemon compiles and links cleanly.

[BIMbeamFLX]

Nice work — the headless mode is the piece that makes Napstr an always-on thing rather than a desktop session, and the Axum server with range requests is doing more heavy lifting than the PR description lets on.

Context for why I'm commenting: I built an independent Napstr client from PROTOCOL.md alone, to run on a small always-on device. It interoperated with the live swarm on the first attempt — 1488 catalogue events aggregated across four relays with zero false rejections against my own validation, a DOWNLOAD_REQUEST answered by a real seeder, and the file verified against its catalogue hash after transfer protocol v2. The spec is accurate and implementable; that seemed worth reporting on its own.

Two things I ran into that may matter for this PR specifically:

Two of the six default relays are unreachable. wss://relay.damus.io and wss://relay.snort.social both answer HTTP 503, measured twice about five hours apart. The other four respond in under a second. A daemon that connects at boot and stays up will wear that differently than a desktop app someone restarts — it may be worth a health check, or trimming the defaults.

The session onion is the weak point for an always-on seeder. The reference flow creates a fresh ADD_ONION NEW:BEST per app session and the onion dies with its control connection, which is right for a desktop client and awkward for a node meant to be reachable for months. In my testing a Tor round trip cost about 16 seconds for a 146 KB file; the same bytes over a direct TCP connection took a millisecond. For a 24/7 seeder that difference compounds.

Which brings me to a question rather than a proposal. This daemon already serves HTTP with 206 range requests from an indexed, hash-addressed library — which is most of a Blossom BUD-01 endpoint (GET /<sha256>, ranges, mirrors) without inventing anything. And DownloadOffer has no deny_unknown_fields anywhere in the tree, so an additional endpoint field alongside onion is ignored by stock clients rather than breaking them. That leaves room for a seeder to advertise a second, cheaper route while staying fully compatible with every existing client.

The route I've been testing for that second path is FIPS, which gives each node an authenticated <npub>.fips address that works behind NAT without port forwarding — the same problem Umbrel users hit. My device runs FIPS and a Blossom store already (BIMbeamFLX/napstr-totem).

Being explicit about what I have and haven't proven, because it matters: interoperation with the public swarm is verified in both directions, including serving my own file over a real v3 onion and fetching it back. The extension field is verified additive. I have not yet moved a single byte over the mesh transport itself — that leg is blocked on a firewall rule on my side, not on anything in the design — and I have not run Blossom over it either. So this is a direction with partial evidence, not a finished thing.

Would a second transport be interesting to you at all, or is Tor-only a deliberate boundary for Napstr? Happy to keep it to myself if so — I'd rather ask before building toward something you don't want. If it is interesting, the smallest useful proof is probably one seeder, one downloader, one encrypted file, verified over both routes from the same offer.