fix(copilot): exact resume via pinned session id, synthetic focus events, left-arrow conflict

[aksOps]

Fixes three copilot-under-uam defects reported together: Ctrl+X r starting a fresh conversation instead of resuming, the composer rendering unfocused (dead to input) after resume, and the attach client's quick-detach stealing copilot's left-arrow pane navigation.

Resume starts a new conversation

uam restart was verified to pass --resume=<uam-id> correctly; the failure is on the matching side. Verified against Copilot CLI 1.0.77 with an isolated $HOME: when --resume's value matches nothing, interactive copilot shows only a small toast ("No session or name matched") and silently starts a new session — exactly the reported symptom. The old adapter depended entirely on --resume falling back to name matching against the --name seeded at dispatch.

uam session ids are already UUIDv4, and --session-id <uuid> sets the primary id of a new copilot session. Dispatch now passes --session-id <uam-id> --name <uam-id>, so --resume=<uam-id> matches by primary session id — the most stable lookup the CLI offers. --name keeps seeding the same value for display and as the fallback match for sessions dispatched by older uam versions (unchanged resume flag value works for both generations).

Verified against the real CLI (1.0.77, isolated $HOME): --session-id creates the session with that exact UUID, --resume=<uuid> resolves it (resume-auto-cd: resolved persisted cwd in debug logs), a miss reproduces the silent-new-session behavior. Verified end-to-end with a logging shim on PATH: dispatch → --yolo --session-id <id> --name <id>, restart → --yolo --resume=<id>, uam record intact.

Composer unfocused after resume

Copilot enables focus reporting (?1004h, PTY-verified along with ?1049h ?1003h ?1006h ?2004h). Under a detached host no terminal ever sends it a focus-in, so it starts believing it is blurred; terminals that don't emit a focus event when the mode is enabled by replay (common over SSH/mobile clients) never correct that. The host now synthesizes \x1b[I when a controller attaches (or when the provider enables ?1004 with a controller already attached — how every resume starts, since the client attaches while the replacement process boots) and \x1b[O when the last controller detaches. A providerFocused flag dedupes the two racing observation paths; forwarded real terminal focus events are untouched.

Left arrow detaches instead of navigating

The bare-left-arrow quick detach assumes left arrow is a no-op at an empty prompt (Claude Code semantics). Copilot binds it to pane navigation. ProviderTerminalPolicy gains a BackDetach field; copilot sets BackDetachDisabled as its default. Profiles, session overrides, and the env override still win.

Tests

• TestHostSynthesizesFocusEventsAtAttachBoundaries / ...WhenModeArmsAfterAttach (in-process host, real attach machinery)
• TestFocusReportingTracksMode1004 (vterm)
• copilot adapter dispatch/resume argv assertions updated for --session-id
• provider policy matrix + resolver precedence tests for BackDetach
• todo8 byte-exact fixture now expects the deterministic leading focus-in; todo11 fake provider exit marker tolerates the merged focus prefix
• full -race suite green locally except TestWizardWorkdirShowsNoGitWarning, which fails identically on clean main in this environment (pre-existing, unrelated)

Unverified: the resume fix against an authenticated copilot install (none on this machine) — the CLI-side semantics above were verified unauthenticated, where session creation/resolution works offline.