Assist mic fails silently ('Oops, an error has occurred') with zero trace client or server side - text input works fine

### Description

Assist voice input consistently fails with a generic "Oops, an error has occurred" toast, both from the home screen Assist widget and from the native Assist screen inside the app. Text input to the same Assist conversation works perfectly every time. This is 100% reproducible across many attempts over one evening, both away from home (mobile data, connecting via Home Assistant Cloud/Nabu Casa remote UI) and on home WiFi.

### What we've ruled out (with evidence)

- **Not a server-side config issue.** Enabled DEBUG logging on `assist_pipeline`, `conversation`, `cloud`, `stt`, `wyoming`, and `mobile_app` via `logger.set_level` (no restart). Across multiple reproduced failures, **zero log lines** were emitted by any of those components — not even a connection attempt. Confirmed via `docker logs` on Home Assistant Core.
- **Not microphone permission.** Confirmed `RECORD_AUDIO` is granted (Android Settings → Apps → Home Assistant → Permissions → Microphone → Allowed).
- **Not the Assist pipeline itself.** Typed input to the exact same conversation agent works correctly every time, including complex responses.
- **Not the home-screen widget specifically.** Reproduces identically from the native in-app Assist screen too.
- **Not an active-media/audio-focus conflict.** Reproduced with no other app holding audio focus.
- **Not Nabu Casa Cloud reachability.** `remote_enabled: true` in `.storage/cloud`, the `*.ui.nabu.casa` remote domain returns `HTTP 200` directly, and text-based Assist over the same remote connection works fine.
- **App's own local log (Settings → Companion app → Troubleshooting → Show and share logs)** shows the native `AssistActivity` opening, then `visibilityChanged newVisibility=false` about 1.2 seconds later, with **no logged exception, no logged network call, nothing** in between. It appears to self-terminate silently rather than crash or throw.

### Environment

- Home Assistant Companion for Android
- Server: Home Assistant Core, connected via Home Assistant Cloud (Nabu Casa) remote UI
- STT: Wyoming protocol add-on (faster-whisper), confirmed independently healthy (its own container log shows successful transcriptions of unrelated test audio)
- TTS: Piper add-on
- Conversation agent: custom LLM-backed agent (not the default Assist)

### Steps to reproduce

1. Open Assist (widget or in-app), see the default "How can I assist?" greeting
2. Tap the microphone icon
3. Observe "Oops, an error has occurred" within ~1-2 seconds
4. Check Home Assistant Core logs (even at DEBUG level for `assist_pipeline`/`conversation`/`mobile_app`) — nothing was logged for the attempt
5. Type the same request instead — works correctly

### What would help us narrow this further

Given the total absence of any error trace on both client and server sides, is there a lower-level log (e.g. audio recording / codec initialization) that isn't captured by the Companion app's "Show and share logs" export? Any known interaction between the native Assist audio pipeline and Home Assistant Cloud's remote UI proxy that could cause a silent, pre-network failure like this?

Happy to provide `adb logcat` output, HA debug logs, or anything else that would help.

Start at the native AssistActivity entry point and reproduce the microphone failure from both the widget and in-app Assist screen. Capture adb logcat alongside the Companion app troubleshooting export, then compare the timing with Home Assistant Core logs, which currently show no request. Done means identifying the pre-network failure and documenting or fixing it with a regression check.

Written by the indexing model from the issue text.