mux d endpoint announces the default key, not the listener's --key

open   by a73x

`mux d endpoint` announces the key from the DEFAULT path, never the listener's `--key`.

`announceKey` in src/cli/main.zig resolves `MUX_KEY_FILE` then `xdg.keyPath` and passes `null` for the explicit-path slot (`xdg.pickKey(null, ...)`), because `endpoint` is a separate process with no way to learn the running daemon's `--key`. The daemon itself honours `--key` (e2e 'daemon honours MUX_KEY_FILE, and --key beats it' is green), so the listener authenticates with one key and every ssh handoff announces another. Symptom: a daemon started as `mux d start -d --quic ADDR --key ELSEWHERE` answers `[unreachable]`-style handoff failures on every `mux HOST` dial; the QUIC dial with the announced key is refused and the client stays on ssh or fails, depending on the path.

Found by `make xos` on 2026-09-03; predates the macOS branch and is not Darwin's. The gate uses the default key on the Linux box to sidestep it. Recorded in docs/decisions.md under 'Two bugs make xos surfaced'.

Fix shape: the announce should ask the DAEMON which key it listens with rather than resolve one of its own. Either the `endpoint_req` reply carries the key path (or a fingerprint) alongside the port, or the daemon writes its key path beside the socket at bind. Resolving a second time client-side can only agree by accident.

Pin: an e2e leg that starts a daemon with `--key` at a non-default path and dials it through `mux d endpoint`; today that leg fails.