fix(voice): honor PIPEWIRE_REMOTE in WSL audio detection

[Solitud1nem]

fix(voice): honor PIPEWIRE_REMOTE in WSL audio detection (was PULSE_SERVER-only)

Branch: fix/voice-wsl-pipewire
Commit: fix(voice): honor forwarded audio (PIPEWIRE_REMOTE) in WSL detection

What

In detect_audio_environment() (tools/voice_mode.py), the WSL detection block
now honors any forwarded sound server (has_forwarded_audio = PULSE_SERVER
or PIPEWIRE_REMOTE or a reachable Pulse socket), mirroring the SSH and
container blocks. Previously the WSL block checked only PULSE_SERVER.

Why

The SSH block (#35622) and the Docker/container block (#21203) already gate on
has_forwarded_audio, which includes PIPEWIRE_REMOTE. The WSL block was the
odd one out — it only looked at PULSE_SERVER. As a result, a WSL user with
PipeWire forwarding (PIPEWIRE_REMOTE set, no PULSE_SERVER) gets a hard-fail
warning and voice mode is blocked, even though audio works.

This surfaced by running the test suite on a real WSL2 machine: the three
TestDetectAudioEnvironment::test_docker_with_pipewire_remote_* tests fail on
WSL and pass on Linux CI. Root cause: on WSL /proc/version contains
microsoft, so the WSL block runs; with PIPEWIRE_REMOTE (not PULSE_SERVER)
it appended a hard-fail warning → available=False. On Linux CI the WSL block is
skipped, so the same tests pass — which is why this slipped through.

Change

• tools/voice_mode.py: WSL block uses has_forwarded_audio instead of only
  os.environ.get('PULSE_SERVER'); notice/warning text updated to mention the
  PipeWire option (consistent with the container block).

How to test

# New hermetic regression test (mocks /proc/version → reproduces WSL on any host):
pytest tests/tools/test_voice_wsl_pipewire.py -v
# The three pre-existing WSL tests now pass on WSL too:
pytest tests/tools/test_voice_mode.py::TestDetectAudioEnvironment -v

The new test_wsl_with_pipewire_remote_allows_voice fails on current main
(available is False due to the WSL warning) and passes with this change.
Complementary tests confirm PULSE_SERVER still works and that WSL without
any forwarding is still correctly blocked.

Verification done

• New test: 3 pass with fix; the PIPEWIRE one fails on main (proven via stash).
• tests/tools/test_voice_mode.py: no regression from this change (the WSL
  pipewire cases now pass; any TestPulseSocketReachable failures are
  pre-existing environment artifacts — that function is untouched here).
• ruff --select F,PLW1514 and scripts/check-windows-footguns.py on changed
  files: clean.

Platforms

Fixes WSL2 (Python 3.11). No-op on non-WSL hosts (the block only runs when
/proc/version contains microsoft); Linux/macOS behavior unchanged.

Scope

One block change + a regression test. Completes the SSH (#35622) / container
(#21203) audio-forwarding pattern for WSL.

[teknium1]

Thanks for the focused regression fix. Current main still computes has_forwarded_audio from PULSE_SERVER, PIPEWIRE_REMOTE, and a reachable socket at tools/voice_mode.py:154-158, but the WSL guard at tools/voice_mode.py:193-206 checks only PULSE_SERVER. The proposed substitution therefore fixes the live PIPEWIRE_REMOTE-only WSL path and matches the existing SSH/container handling at tools/voice_mode.py:163-191.

The new hermetic WSL test covers the missing case without requiring a WSL runner, while retaining positive PULSE_SERVER and negative no-forwarding cases. The cross-referenced PR #59357 was closed as a duplicate of this canonical fix, not as superseded.

Automated hermes-sweeper review.

[teknium1]

Merged into main via consolidated salvage PR #73520 (merge e04c2a9ebd). Your WSL PIPEWIRE_REMOTE forwarding detection was cherry-picked with your authorship and merged with the #68604 gate.

Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage.