#32098 fix(focus): a new workspace's keys during a surface hold go to its terminal; a held line for the focused terminal is never lost

Summary

These are two key-routing defects where the person's new-workspace key hold (#31865) meets the REOPEN-F4 surface hold (#31707). The merge review of #31865 found them (https://github.com/manaflow-ai/cmux/pull/31865#issuecomment-6572422551).

1. A key typed for the person's new workspace went to another cold terminal. A key typed into a cold focused terminal T opens #31707's surface hold, which gives T an adopted (negative) lane. The person then asks for a new workspace W in the same window. CreationInputBuffer.capture preferred the focused lane, so the keys typed for W before W showed went to T. Now an adopted lane gives way to the person's new-workspace ticket. The keys typed after the request go to W's terminal, and the keys typed before it stay T's.
2. A replayed key held for a terminal was lost at the hold limit. The hold ends at its limit while W is still hidden. The keys held for the terminal that has the keyboard then run again as typed. The person's keyboard claim kept every replayed key that runs no binding, so that line was lost. Now a replayed key that was held for a terminal goes to it. The claim keeps only replayed keys that were typed for no terminal.

Both defects need W to stay hidden for 2 s after the create replies. No key reaches an agent (T is a terminal). CmuxNextApp lines: +0.

REOPEN-F4 owner (a02ba201): this changes how keys route through your #31707 hold. Please read it; you were told in STATUS 5995 and on #31707.

Testing

• Red at 31df1f23190 (tests only, on feat fc12029e0e46 + #31865): step 9fc5b757fdd23094737c4c6c (aws-m4pro-7). It FAILED as expected:
  • CreationInputHoldTests.keysForAPersonsNewWorkspaceTypedDuringASurfaceHoldGoToTheNewTerminal: routed ["a:cold", "b:cold", "c:cold"]; the expected result is ["a:cold", "b:new-terminal", "c:new-terminal"].
  • SecondCreationKeysTests.keysHeldForTheFocusedTerminalReachItWhileAPersonsNewWorkspaceClaimHolds: the held line never ran in the focused terminal.
• Green 5x at head 029aa80113b: step a0babca96e650cf1b3770705 (aws-m4pro-2). All 30 suites passed: CreationInputHoldTests, SecondCreationKeysTests, HomePendingTerminalFocusTests, PersonTerminalKeyboardClaimTests, ColdFocusedTerminalTypeAheadTests and FocusedPanePresentedFirstTests, 5 of 5 each.
• Compile-check of the head (app + CmuxNext, recipe 2): passed. The red ref also compiled (job d97009e21a6355adc15ce0b1).

Observed / Not run

Observed: the fleet steps above. Not run: a live journey, a tagged build, and the real-HID sequence (cold reopen, type, click New Workspace, type).

Changelog

Fixed: Keys typed right after you ask for a new workspace no longer go to a terminal that was still opening, and a line held for the focused terminal is no longer lost.

Proof

No capture: key routing only; the tests check it.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes two key-routing defects where the new-workspace key hold (#31865) meets the surface hold (#31707), so a new workspace's keys reach it and a held line for the focused terminal is never lost.

• Keys typed for a new workspace asked for during a cold terminal's surface hold now go to the new workspace's terminal; before, they went to the cold terminal because its adopted lane was preferred.
• A replayed key held for the terminal that has the keyboard reaches that terminal when the hold ends at its limit; before, the new-workspace claim kept it and the line was lost.
• Both defects needed the new workspace to stay hidden for 2 s after the creation replies.

Testing

• Red at the parent commit (tests only), green 5x at head; all 30 suites passed.