#30271 P0 port: keys typed after Cmd-N then Ctrl-` reach the new terminal (#30827, #29530 keys part)

Summary

• Keys part of the #29530 port to the dogfood line cp/dogfood-v2-2-12-opt. The opening part landed as #31034 (merge 1f0153f6170). Net change against that tip:
  • Cherry-pick of feat #30827 (feat d7128e651abe; here 673b6bf25e8). CreationInputCoordinator.begin ends the window's New Tab page hold (NewTabInputCoordinator.creationTookKeys) once its own hold is open. The keys that hold kept replay, in typing order, into the creation hold. Before, after Cmd-N then Ctrl-` (or Cmd-D), the keys typed next waited for the New Tab page and went to its field: smoke round 2 step 16's typed line.
  • Test seam CreationInputCoordinator.replay (feat's HeldKeyReplay, #28436). The default is NSApp.sendEvent, as before, so product behavior is unchanged.
  • Tests: CmdNThenCreateKeysTests (#30827's, for Ctrl-and Cmd-D; it records a diagnostic only when it fails) and #29530'skeysTypedWhileCtrlBacktickWaitsForCmdNAreHeldForTheNewTerminal`. Each requires the focused tab to be a new terminal, its screen to show the typed line and the shell's answer, and no other terminal to show the line.
  • Test harness: PasswordManagerRouteTests.withApp calls GhosttyRuntime.startedForTests(). On this line the app starts the Ghostty runtime at launch; on feat it starts on first use. Without the call, the harness's terminal views have no surface and type nothing (diagnostic 12f65c19335cf44d44de0317). That made the earlier screen-oracle failures on this line (37f96e2b, 3f0893af) harness failures, not product failures.
• Dropped along the way: a dogfood-only stand-in early-tab rule (28bcb1b50cbe). Probe 7ec3a8abe34e5cbc20966aae showed it is not needed, so this line's early-key path is unchanged. No #29301 port is needed (STATUS 4006).
• STATUS 3968 (pa-d's round 2: the Ctrl-key itself held, empty trace): NOT proven fixed. These tests callnewSurface directly; they do not press a Ctrl- key. Which hold kept that key (the New Tab hold or the creation hold, which holds chords while one of its creations is pending) is not known. pa-d's next judged rounds record it.

Testing

• Compile at the head 16891d14e6de: bc1c6d1a65cee7dc17ba0a9c passed (CmuxNext with tests, app, cmux-tui).
• Red bac8b631e19bb81a12332906 at 95dbc9427814 (the same tests and harness, New Tab hold release off): CmdNThenCreateKeysTests failed 2/2 on the screen check (sh-3.2$; every key "New Tab hold true"). #29530's key test passed there: it does not discriminate this fix.
• Probe 7ec3a8abe34e5cbc20966aae at 66e36b74b33c (the head's product code): the 5 key tests passed.
• Green 0f44c923195bc87faf36079e at the head (display, CMUX_TEST_REQUIRE_GUI=1; CmdNThenCreateKeysTests, CmdNThenNewTerminalTabTests, CmdNStandInTargetTests, PaneVerbOnPendingPaneTests, EarlyTerminalKeysTests, NewTerminalOnPendingSplitTests): PASSED, all 6 suites (2+3+5+5+9+1 tests), gui-session-v1 console line present, no FLAKY. CmdNThenCreateKeysTests 2/2: the typed line and its answer show in the new terminal for Ctrl-` and Cmd-D.

Observed / Not run

• Observed: the fleet results above, read in their logs.
• Not run: the other withApp suites at the head (the harness now starts the runtime in all of them, as the app does); a real Ctrl-` key press (smoke rounds); New Column and New Row after Cmd-N.

Changelog

• Fixed: after Cmd-N then Ctrl-` (or Cmd-D), the keys typed next reach the new terminal, not the New Tab page.

No capture: key routing; the evidence is the display-worker screen oracle.
perf claim: none.