Mobile 0.4.12 does not decode Desktop 0.5.0 styled pairing QR

## Summary

Buzz Mobile 0.4.12 on iOS does not advance after scanning the pairing QR generated by Buzz Desktop 0.5.0. The pairing relay sees only the desktop connection. No phone WebSocket or reverse-proxy `/pair` request appears.

## Environment

- Mobile: Buzz Mobile 0.4.12, iOS
- Desktop: Buzz Desktop 0.5.0, macOS
- Relay: self-hosted Buzz 0.5.0
- Pairing endpoint: public WSS endpoint at `/pair`
- The deployment fixes from #2734 and #3291 are applied:
- `buzz-pair-relay` runs as a separate service
- the reverse proxy routes `/pair` with WebSocket upgrade headers
- a direct WebSocket probe receives `101 Switching Protocols`

## Reproduction

1. In Desktop 0.5.0, open Settings > Mobile.
2. Start a pairing session.
3. In Mobile 0.4.12, scan the displayed QR.
4. Mobile does not advance to the security-code step.

## Server evidence

```
10:31:14 desktop connection opened, active=1
10:33:14 desktop connection closed, active=0
```

No phone connection or `/pair` request occurs during the scan. This places the failure before the mobile client opens the pairing WebSocket.

## Expected behavior

Mobile should decode the pairing URI, open the target WebSocket while the desktop session is active, and continue to security-code verification.

## Suspected regression boundary

- #2739 added the adaptive QR scanner used by Mobile 0.4.12.
- #2775 added the styled pairing QR used by Desktop 0.5.0.

The desktop test decodes the rendered QR, but it does not appear to test the actual Mobile 0.4.12 scanner against that styled image.

## Suggested regression test

Render the Desktop 0.5.0 styled pairing QR and pass it through the Mobile 0.4.12 scanner pipeline. Assert that the scanner emits the full URI and opens the target WebSocket. Include a plain QR as a control case.

Related: #2324, #2734, #3291.