Host resume (#30): upstream PTY pane-copy census flags host-pane-agent-resume-start.ts #54

Upstream's PTY pane-copy census (src/main/runtime/terminal/surface/pty-pane-copy-census.test.ts, the "L80" census) fails on a fork file:

PTY record pane copies (L80) > are touched only by paneOfPty and the switch-guarded writers
+ "src/main/runtime/session-lifecycle/projection/host-pane-agent-resume-start.ts:130 prepareHostPaneAgentResume"

Where. Host resume after terminal loss (#30). prepareHostPaneAgentResume builds isPaneTerminalLive by reading each PTY record's paneKey copy directly:

const isPaneTerminalLive = (candidate: string): boolean =>
  [...this.ptysById.values()].some((pty) => pty.connected && pty.paneKey === candidate)

The census allows a PTY record's tabId / paneKey copies to be read only through paneOfPty (src/main/runtime/terminal/surface/pty-pane-query.ts). That function branches on ORCA_LAYOUT_OWNER_IS_MAIN: when main owns the layout, the pane comes from main's binding, not from the record's copy.

Seen in. Sync PR #53, unit shard test / tests node 24 1/5 (job).

Not new with #53. The same test fails locally on minidev-alex1 on the integration head from before that merge (7d33e616ae). The census and the fork file are both unchanged since sync #38 (1a247d1c5c). Earlier sync PRs probably did not select the test in their unit shards.

Suggested fix (I believe the census is right). Resolve the pane with paneOfPty(pty, mainPaneOf) instead of pty.paneKey, so a layout-owner build answers from main's binding. Then run the census and the fork's host-resume tests (host-pane-agent-resume*.test.ts, server-terminal-loss-resume.test.ts). The fix goes through a PR into swaplabs/main; the merged sync branch takes no fixes.