Network-based trainers (DIRCON on the LAN) may not be discovered when TPV runs under pasta networking #13

Context

To fix the TrainingPeaks Hub app taking ~130 s to connect (#3, PR #8), run-tpv.sh is moving from --network=host to --network=pasta:-i,<LAN interface>. Under pasta, Wine only sees the LAN interface, so TPV stops advertising Docker/VPN addresses the phone can't reach. Cold-start Hub connections dropped from ~132 s to 3-4 s.

Concern

TPV discovers DIRCON trainers over mDNS (_wahoo-fitness-tnp._tcp). pasta doesn't appear to forward inbound multicast from the LAN into the container's network namespace. That means TPV may no longer discover trainers that advertise themselves on the network, for example:

• a Wahoo KICKR / KICKR CORE with built-in Wi-Fi or Ethernet (DIRCON)
• a separate DIRCON bridge on another machine (e.g. QZ on a phone or another PC)
• the soak test's stand-in trainer (tools/soak/fake_dircon_trainer.py), which runs on the host

The default both mode is different. QZ runs in the same container and publishes its advert through the host's avahi over D-Bus, so TPV connects to it inside the same network namespace. That path is being verified separately with a real ride.

Workaround

TPV_NETWORK=host ./run-tpv.sh restores host networking. The Hub app then connects slowly on cold starts while Docker/VPN interfaces exist.

To investigate

• Confirm whether TPV under pasta discovers a DIRCON advert from the LAN (the stand-in trainer on the host is a quick test)
• If not: pasta/podman options for multicast, or relaying _wahoo-fitness-tnp._tcp adverts into the container
• Decide whether to auto-detect (fall back to host networking when QZ_TRAINER is unset / TPV_DIRECT=1)