fix: release held modifiers when press_key key event fails

[Liohtml]

What

press_key currently presses each modifier down, presses the main key, then releases the modifiers — in three sequential steps with no try/finally:

for (const modifier of modifiers) {
  await page.pptrPage.keyboard.down(modifier);
}
await page.pptrPage.keyboard.press(key);      // if this rejects…
for (const modifier of modifiers.toReversed()) {
  await page.pptrPage.keyboard.up(modifier);  // …this never runs
}

If keyboard.press(key) rejects — a CDP hiccup, a target crash, or a dropped connection — the release loop is skipped and the modifier keys are left logically held down in the browser. waitForEventsAfterAction re-throws the action error, so nothing downstream releases them either.

This is the unpaired-keyDown class of defect asked about in #2309 ("whether any code path sends a keyDown without a guaranteed matching keyUp on an error/timeout branch"). This PR fixes the one concrete instance of it in this repo.

Fix

Wrap the down/press sequence in try/finally and track which modifiers were actually pressed, releasing each held modifier even when the main press throws. Only modifiers whose keyboard.down() succeeded are released, so a failure while pressing a modifier doesn't emit a spurious keyUp.

Test

Adds a regression test (real browser, keydown/keyup logging) that injects a press() failure mid-sequence and asserts both modifiers are still released. It fails on main (['dControl','dShift'] — no keyups) and passes with the fix (['dControl','dShift','uShift','uControl']).

Verified locally: full tests/tools/input.test.ts suite passes, npm run typecheck, eslint, and prettier all clean.

Scope note re: #2309

I want to be precise about what this does and does not address. This closes a browser-level stuck-key path: leaked keys here live in Chromium's input state (CDP Input.dispatchKeyEvent is injected into the renderer), so the observable effect is a modifier stuck within the driven page. The report in #2309 is a bare Space that repeats system-wide and survives physically unplugging the keyboard — that symptom is at the OS input layer, which CDP-injected input doesn't route through, so I don't claim this fully explains that case (details and a non-reboot workaround are in a comment on the issue). Still, an unpaired keyDown on an error branch is a real defect worth closing on its own, and it's exactly the code path the issue asked to audit.

Prepared with AI assistance (Claude Code) and verified against a local build before submission.

[Liohtml]

Rebased on main. The CI red was the McpContext getter refactor (#2342 and friends) landing after I branched — getSelectedPptrPage() is gone, so my new test failed to compile against the merged tree. Updated it to getSelectedMcpPage().pptrPage. Green locally across the full input suite, typecheck + lint clean.

[OrKoN]

Thanks!

[OrKoN]

@Liohtml I have seen #2353 and I just want to clarify something here: this code is an improvement but generally if press fails also keyboard.ups would fail because the usual cause is something like the page is closed/crashed. Do you actually have realistic scenarios when this would fail on healthy pages?