arch(browser): multi-instance orchestration / pooling behind the canonical interface #12761

Part of #12756. Depends on: #12651 (canonical interface).

Problem — single Chromium, no orchestration/pooling

The live browser is one Chromium process on one browser-worker host; sessions are BrowserContexts within that single process (autobot-browser-worker/playwright-server.js:108-155, pre-init :1150-1152). There is no pool of browser instances, no horizontal scaling, and no per-instance routing. This is a real scaling ceiling for parallel agent/QA workloads.

PinchTab's control plane manages multiple Chrome instances (headless/headed, across containers/remote) behind one server with per-instance routing and isolated profiles.

Task

Behind the canonical browser interface from #12651, add an orchestration layer that can manage N browser instances (headless/headed) with per-instance routing and profile binding, so multiple agents / QA jobs can run in parallel without contending on one Chromium. In-proc single-instance stays the default; pooling is opt-in.

Sequencing / priority

• Must land after tech-debt(backend): unify two Playwright browser stacks behind one interface #12651 (needs the single interface first).
• Medium/low priority — architectural; do only when parallel-load demand is real. Not a blocker for the security/efficiency children.

Files (indicative)

• autobot-browser-worker/session-store.js (→ instance-store), playwright-server.js (instance lifecycle).
• autobot-backend/api/browser_mcp.py (routing to a selected instance).

Done when

The canonical browser can start/stop/route across multiple isolated instances; a parallel multi-instance workload runs without cross-talk; tests cover instance lifecycle + isolation.