fix(remote): keep desktop relay reconnect alive under backpressure

[wgqqqqq]

Summary

Fixes desktop Remote Connect staying offline after the relay closes its WebSocket while device RPC events are under load. The PR also includes the local HarmonyOS account-startup race fix.

Fixes #

Type and Areas

Type: regression fix

Areas: Rust core, remote connect, HarmonyOS mobile

Motivation / Impact

The relay client used non-blocking sends for bounded event queues and treated a full queue like a closed consumer. That could terminate the receive loop and the only reconnect task, leaving the desktop device offline until the app was restarted. Event delivery now applies backpressure without terminating the transport, and graceful Socket.IO teardown has a timeout.

HarmonyOS initializes the account store before the rest of cold-start work and serializes initialization so an early login tap cannot race session-store setup.

Verification

• pnpm run fmt:rs
• cargo test --locked -p openbitfun-services-integrations --no-default-features --features remote-connect --lib remote_connect::relay_client::tests:: — 5 passed
• cargo check --locked -p openbitfun-core --no-default-features --features remote-connect — passed
• git diff --check — passed

Reviewer Notes

The reconnect regression test fills the event queue and verifies routing waits for capacity instead of dropping the connection. Existing local HarmonyOS changes are intentionally included in this branch so the account-login and relay reconnect fixes can be tested together.

Checklist

• This PR is focused and does not include secrets, temporary prompts, generated scratch files, or unrelated artifacts.
• Relevant verification is recorded above.
• User-facing strings, docs, and locales are not changed by this fix.