Your diagnosis is right, and it’s a platform limitation rather than anything wrong with your package. Every StartOS service runs in a container on a NAT bridge, and there is currently no supported way to give a service L2/LAN presence — no host networking, no macvlan — and multicast (mDNS/SSDP) is not reflected between the LAN and the container network in either direction. That’s exactly why you see 0 responders inside the container and 15 on the host, and why upstream Music Assistant mandates host networking or macvlan for Docker installs.
What StartOS can do today: fixed ports can be exposed raw (plain TCP, and TCP+UDP for port ranges) on the server’s LAN IP via the SDK (secure: { ssl: false } on a bind, or bindPortRange), and outbound connections from the container to LAN devices work. So a degraded-but-useful package may be possible: the web UI, plus players added by manual IP for the providers that support it (Google Cast, Sonos, HEOS, Sendspin) — provided Music Assistant can be configured to advertise the server’s LAN IP and a fixed stream port that the package forwards. If you test that combination I’d be very interested in the result. AirPlay, DLNA, and Squeezebox discovery rely on multicast or dynamically-negotiated ports and cannot work under the current model, and I’d steer you away from privileged-container hacks — they’ll fight the OS’s networking and break on update.
The real fix is a platform feature: opt-in LAN access for a service, granted by the user. These types of features, including various other types of hardware pass-through, are slated for future versions of StartOS.