Drop unused direct muontrap dependency

[bbangert]

Closes the underlying problem behind #157, which cannot be merged as-is.

Why #157 can't work

Renovate's #157 bumps muontrap to ~> 2.0, and CI fails all six checks at mix deps.get:

Because "your app" depends on "bluez ~> 0.1" which depends on "muontrap ~> 1.8",
"muontrap ~> 1.8" is required.
So, because "your app" depends on "muontrap ~> 2.0", version solving failed.

The resolver names bluez first, but it is not the only blocker — three deps pin muontrap 1.x:

Consumer	Constraint
vintage_net	~> 0.5.1 or ~> 0.6.0 or ~> 1.0
nerves_time	~> 0.5 or ~> 1.0
bluez	~> 1.8

Two of those are upstream (fhunleth's), so no amount of editing our mix.exs resolves this. The only way to force it is override: true, which would make this app assert muontrap-2.0 compatibility on three libraries — for a dependency it does not use.

The actual fix

We never use MuonTrap. An exhaustive search finds zero call sites; every mention is prose explaining why it is deliberately avoided:

Why raw Port (no MuonTrap)

MuonTrap.Daemon closes stdin and routes stdout through Logger — unusable for bidirectional JSON IPC. Wrapping muontrap with --capture-output requires implementing its byte-ack protocol and loses {:line, N} packet framing.

— lib/universal_proxy/audio/player.ex:23

So the direct declaration was vestigial, and its comment ("Supervised OS process management for the sendspin_player C++ binary") described the opposite of what the code does.

Removing it means muontrap resolves purely as a transitive of the three libraries above. mix deps.tree now shows it only under them.

Impact: none

• mix.lock is byte-for-byte unchanged — muontrap stays at 1.8.0
• The release still ships the app and its port binary: _build/rpi3_dev/rel/universal_proxy/lib/muontrap-1.8.0/priv/muontrap (vintage_net needs it at runtime)

Follow-up (not in this PR)

muontrap 2.0's only breaking change is cgroup v1 → v2, and its changelog says "If you don't use cgroups, this update is not breaking for you. Library authors are encouraged to allow both MuonTrap v1 and v2." None of vintage_net, nerves_time, or bluez reference cgroups at all. bluez is ours — widening it to ~> 1.8 or ~> 2.0 would be correct hygiene, though it still would not unblock v2 here until the two upstreams widen too.

Recommend closing #157.

Verification

• mix compile --warnings-as-errors — PASS (exit 0)
• mise run test — 930 passed, 3 excluded
• mix dialyzer — PASS (7 errors, 7 skipped, 0 unnecessary skips)
• mise run firmware -- rpi3 — PASS, muontrap present in the release

🤖 Generated with Claude Code