fix(cloud): close the create-to-persist crash window

[MagMueller]

What Problem This Solves

A hard crash after Browser Use Cloud accepted POST /browsers but before Browser Harness persisted the returned browser ID could leave a billable browser with no exact cleanup handle.

Why This Change Was Made

Browser Harness now persists a fresh project-scoped client idempotency key before network I/O and sends it as clientSessionId. Cloud keeps its own tenant-scoped browser ID and exposes a lookup from the client key to that exact ID.

Recovery state is versioned and checksummed:

• existing v1 records containing an exact browser ID remain readable;
• v2 first stores the client key, then atomically enriches the same record with the server browser ID after a successful response;
• after SIGKILL or a lost response, cleanup resolves the key through GET /browsers/client-session/{key} and PATCHes the exact returned browser;
• a 404 means the server never claimed the key, so the local recovery record can be cleared safely;
• caller-provided clientSessionId remains rejected so cleanup authority stays internal.

User Impact

• Public Browser Harness commands and local/profile daemon behavior are unchanged.
• Cloud creation becomes recoverable across the former POST-to-persist crash window.
• Existing durable v1 recovery records remain backward compatible.
• This PR is stacked on feat: harden orchestrator-owned browser daemons #626 and depends on Browser Use Cloud #5609. It must not ship until that API is deployed and BROWSER_CLIENT_SESSION_ID_ENABLED is enabled; an older or gated-off API rejects the new field.
• Do not roll the Cloud API back while this Browser Harness version can create new Cloud sessions; disable/drain the client first.

Evidence

• Full Browser Harness suite: 188 passed.
• python -m compileall -q src tests: passed.
• git diff --check: passed.
• Regressions cover pre-POST durability, atomic pending promotion, distinct server IDs, key-only crash lookup and exact stop, 404/no-resource recovery, startup cleanup retention, persistence failures, and caller override rejection.
• Browser Use Cloud #5609 received a separate independent correctness and customer-impact review before this PR was made ready.
• The exact combined Browser Harness candidate was exercised by the final Hermes 106-task Cloud-browser evaluation: 92/106 semantic passes, 106/106 explicit remote-browser stops, zero Harness IPC timeouts, and zero screenshot capture errors.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}