Voice mode constructs MCP connector tool calls but never dispatches them — regression of working behavior (ref #146)

#146 reported this and was closed "not planned." I have server-side evidence this is a REGRESSION, not a missing feature.

Self-hosted MCP connector (Streamable HTTP, OAuth 2.1 + PKCE + DCR). In typed chat, every tool call reaches my origin and succeeds — request-level logs confirm 100%. In voice mode, the tool-call chip renders (correct tool name), but ZERO HTTP traffic reaches my origin. Claude then invents explanations ("tool isn't registered", "dynamic registration timed out") — the same confabulation described in #146.

**Evidence it is a regression:**
- Voice + this connector worked reliably for days until ~2026-07-20.
- On 2026-07-21 voice dispatch succeeded twice: once mid-session (~11:37 MST, list + read landed and returned content) and exactly once immediately after updating the iOS app — then permanent failure. Force-quit/relaunch does not reproduce; only fresh app state did.
- With a tool set to "Needs approval": typed chat renders the approval card and approved calls land; voice renders no card — dispatch dies before the permission layer.
- Asked to enumerate tools, voice lists only built-ins (calendar/reminders/location/time/web_search); asked to read a file it fired `user_location_v0`. The connector is absent from the voice runtime's mounted set even in conversations where typed turns just used it successfully.

**Eliminated on my side:** network path (public HTTPS; typed calls land seconds before/after voice failures), SSE timeouts (nothing arrives to time out), gateway stateful vs stateless (identical), all client settings combinations, fresh conversations/OAuth/reinstall.

**Ask:** either fix voice-runtime connector mounting/dispatch, or document the limitation in the voice-mode support article (currently silent on connectors) so Claude and users stop debugging a dead end. Full timestamped evidence bundle available (Anthropic support conversation 215475177708993).