feat(window): support multiple application windows for multi-monitor workspaces #688

Motivation

Agent Code is built for running many agents at once, but the whole product is
confined to a single window. On a multi-monitor desk that wastes the second
display entirely: there is no way to put five agents on the main monitor and
another set on the second one. Every comparable editor (VS Code being the
obvious reference) treats "another window on another monitor" as a basic
capability, and for an app whose entire premise is parallel agent work the gap
is more costly here than it is there.

Today the single-window assumption is explicit and load-bearing:

• src/main/window/mainWindow.ts holds one module-scoped BrowserWindow, and
  sendToMainWindow() (53 call sites) is the only outbound IPC seam.
• src/main/workflows/WorkflowBridge.ts:494 and
  src/main/orchestration/OrchestrationBridge.ts:455 both carry
  // a future multi-window product must make this target-aware comments.
• src/main/menu/appMenu.ts ships a plain { role: 'windowMenu' } — there is
  no New Window command anywhere in the app.
• workspace.json is a single whole-workspace snapshot written by one renderer.

docs/archive/issue-investigations/147-multi-instance-policy.md already studied
this and concluded that multi-window must be implemented as additional windows
inside the one existing primary process — never additional Electron mains,
which would put two writers on ~/.config/agent-code and could resume the same
provider session twice. That conclusion still stands and this issue adopts it.

Intended behavior

Each window is its own workspace inside the single existing main process: its
own tabs, panes, Dispatch, and agents. Settings and every disk-owning service
stay global and singleton.

• Window -> New Window opens an additional window; it can be dragged to any
  display and remembers where it was.
• workspace.json gains a window dimension; an existing single-window file
  migrates to windows[0].
• Closing a window is not destructive. Its agents stay alive in
  SessionManager and are adopted as detached sessions by a surviving window,
  where they appear in that window's Dispatch under their original project.
• Session IPC is routed to the window that owns the session rather than
  broadcast to every window.

Known hazard this must not regress

useAutoSave prunes any session metadata it cannot prove is owned, by design
("metadata with no owner cannot make itself durable"). If two windows each
serialize the whole workspace, each one classifies the other's agents as unowned
and deletes them from workspace.json on a 400ms debounce, in both directions.
Per-window save slices are therefore a correctness requirement, not a tidiness
one, and need explicit regression coverage.

Out of scope

• Moving an agent or tab between windows (detach -> reattach already covers the
  case; a dedicated command can follow later).
• Per-window settings. Settings remain global.
• Multiple Electron main processes, which remains prohibited by the Audit and harden behavior with multiple Agent Code instances open #147 policy.

Acceptance criteria

• A second window can be opened, placed on another display, and used for
  independent agents.
• Window geometry, display placement, and per-window layout survive quit and
  relaunch.
• An existing single-window workspace.json migrates without losing tabs,
  sessions, detached records, buried panes, or pins.
• Two open windows never prune each other's sessions out of workspace.json.
• Closing a window leaves its agents alive and reachable from the surviving
  window's Dispatch, under a project tab that matches their origin.
• Closing the last window still follows the existing quit/shutdown path.
• Session events reach only the window that owns the session.
• Menu commands and the dictation hotkey act on the focused window.