fix(harmonyos): recover watch provisioning after interrupted login

[wgqqqqq]

Summary

A phone returning from cloud account authorization can become foreground before its session is saved, leaving watch provisioning inactive. This change starts the listener after login completes and persists an encrypted watch registration identity before contacting the relay so an interrupted handoff can replay the same request and key.

Draft: the recovery lifecycle needs further work before merge.

Type and Areas

Type: Bug fix

Areas: HarmonyOS phone account login and watch provisioning

Motivation / Impact

• Start watch provisioning after successful cloud login, before resuming a pending desktop link.
• Store watch identity through the existing HUKS-encrypted persistence adapter, scoped by relay, account and device.
• Reuse the registration request ID and private key after an interrupted registration/handoff.
• Reject expired approval requests and distinguish an already-registered device from a generic network failure, with Chinese and English messages.
• Add thirteen regression tests for login timing, interrupted handoffs, identity isolation, storage failure, expiration and conflict reporting.

Verification

Passed:

• node --test src/apps/mobile/harmonyos/tools/tests/watch-login-lifecycle.test.cjs src/apps/mobile/harmonyos/tools/tests/watch-provision-recovery.test.cjs — 13 tests.
• pnpm run harmony:architecture.
• From src/apps/mobile/harmonyos: source scripts/ohos-env.sh followed by "$HVIGORW" --mode module -p product=default -p module=entry@default assembleHap --no-daemon — signed HAP build succeeds.
• git diff --check.

pnpm run mobile:architecture fails on existing shared-core contracts: one JVM test reference to the HarmonyOS tree and three public constructors with default arguments. Those files and the checker are unchanged by this PR.

Additional cross-repository verification: node --test tools/tests/device-account.test.cjs from /Users/user/bitfun_wearable — 8 tests passed, including v1 credential interpretation, relay public-key verification, encrypted persistence and legacy-session handling. The wearable working tree was read without modification.

Remote coverage: mocked relay registration and phone-to-watch outcomes only. No live phone/watch handoff, old-relay integration, desktop provisioning fallback, compact/wide/fold transition, remote workspace, Peer Device Mode or Detached Dispatch verification was performed.

Reviewer Notes

Merge blockers / follow-up:

• Cross-repository review of /Users/user/bitfun_wearable confirms that each watch attempt uses a fresh handoff request ID and ephemeral key, while its device ID survives logout. The phone correctly reuses the original relay registration ID but answers/seals to the current handoff request. Do not delete the phone identity simply after handoff success: watch logout clears local credentials without unregistering its relay device.
• Expired-token recovery remains unresolved: the watch handles 401 by asking for phone authorization again, but the phone indefinitely replays the old relay registration. Relay replay requires an unexpired token and the original device name/key. The watch currently uses a fixed device name, so a user rename is not a current caller path, but a future app rename can break replay.
• Follow-up review fixes: CloudAccountClient.provisionDevice now clears its owned private-key copy on request/response failure while retaining ownership transfer on success. Tests cover HTTP failure and mismatched response identity.
• The watch explicitly waits three minutes and documents the phone TTL as five minutes. The phone TTL is restored to five minutes, preserving the existing cross-version behavior; a regression test guards the lifetime margin.
• Add integration coverage for real relay replay and persisted identity loading (including malformed/legacy data). Current tests mock persistence and successful replay.

Existing wire protocol version remains 1. Local signing configuration, certificate paths, provisioning profiles and signing passwords are excluded.

Checklist

• This PR is focused and does not include secrets, temporary prompts, generated scratch files, or unrelated artifacts.
• Relevant verification is recorded above, or skipped checks are explained.
• User-facing strings, docs, and locales are updated where applicable.