#25689 cmux next focus: no reclaim inside the grant of a page that still has focus

Fixes https://github.com/manaflow-ai/cmux/pull/25222 (follow-up): ChildPageFocusKeyChangeTests.aReapplyInsideTheGrantDoesNotGrantAgain() is red on feat-cmux-next. It has failed since https://github.com/manaflow-ai/cmux/pull/24913 added it, and it surfaced when https://github.com/manaflow-ai/cmux/pull/25222's cmux-next swift test run put the suite in its priority filter. Base pushes skip that job.

• What went wrong: the test models a re-apply inside the grant that calls reclaim(into:when:) while the granted page still has focus. reclaim then gave the keys straight back to the cmux window: two key changes for one focus request (["pageB", "cmux"]), with the page still recorded as focused and no keys. No production path is known to reach this today (focusPage never reclaims, and blurChildWindowPage blurs first), so the fix is defensive: it makes ChildPageFocus honor the contract the test states.
• Fix: ChildPageFocus.reclaim does nothing inside the grant of a page that still has focus. keysReturned(to:during:) already treats key changes inside a grant as the grant's own; reclaim now does the same.
• Why scoped to a page that still has focus: in production reclaim runs from blurChildWindowPage, which blurs the page first. If focus moves away during a grant (the model moved on to a terminal), the keys still come back to the cmux window. A new test covers that case.

Changelog

• Fixed: ChildPageFocus.reclaim no longer hands the keys back to the cmux window in the middle of a grant to a page that still has focus.

Tests

The command, on the fleet:

cmux-ci run --class light --script scripts/ci/package-test-lane.sh --ref <sha> --arg=suite --arg=Packages/macOS/CmuxNext --arg=ChildPageFocusKeyChangeTests --env CMUX_CI_XCODE_APP=/Applications/Xcode_26.6.app

• aReapplyInsideTheGrantDoesNotGrantAgain(): the existing test, red on the base.
• reclaimInsideTheGrantAfterThePageBlurredTakesTheKeysBack(): new; it guards the scoping.

Observed / Not run

Results for the command above at cc9622ea43e0c (tests only, expected red) and 6b40dd68f1c58 (fix, expected green) are added in a comment below.

No capture: there is no visible UI change; the fix only decides which window has the keys.

🤖 Generated with Claude Code