fix(browser): stabilize signed-in browser lanes and add explicit live Chrome lane

[artemgetmann]

Review Fast Path

• User path fixed: signed-in browser flows no longer degrade because the cloned user lane fails early on CDP attach, and explicit live-browser tasks now have a real lane instead of overloading user.
• Proof: focused local browser flow on patched runtime succeeded with user (start -> open https://example.com -> snapshot) after previous logs showed repeated browserType.connectOverCDP: Timeout 9000ms exceeded on the same lane.
• Shared-state footgun removed: user and the real live browser are no longer conflated under one semantic bucket, and the runtime ownership rule is now easier for agents to find.
• Still hurts: user-live still needs a post-merge smoke against the real Chrome session from main.

Why This Matters

• The bot was falling back unnecessarily despite a live local CDP socket.
• Users need both behaviors:
  • safe cloned signed-in browsing
  • real live-browser control when they explicitly mean an already-open tab/window
• The primary gateway also needs a clear runtime-ownership rule so the production bot does not drift onto a worktree checkout.

Scope Boundary

• What changed:
  • local loopback CDP attach timing
  • explicit user-live lane
  • chrome alias normalization
  • workflow/runtime/agent guidance for worktree validation vs primary-bot runtime ownership
• What did not change:
  • user semantics remain cloned and safe by default
• What still hurts:
  • live-session smoke for user-live must happen after merge from main

Verification

• Targeted validation:
  • pnpm openclaw:local browser --browser-profile user start
  • pnpm openclaw:local browser --browser-profile user open https://example.com
  • pnpm openclaw:local browser --browser-profile user snapshot --json --timeout 60000
• Outcome:
  • startup, open, and snapshot succeeded
  • old fast attach-timeout symptom did not reproduce in that flow

AI Assistance

• AI-assisted
• Testing degree: targeted