fix: resolve page ids only among listed pages

[thomasbachem]

Follow-up to #2304, and to #2328 which fixed the symptom.

After #2333, getPages() – what list_pages presents – is a filtered view over #mcpPages that excludes devtools:// frontends (unless experimentalDevToolsDebugging is set; they enter #mcpPages via handleDevToolsAsPage). getPageById() still searches all of #mcpPages, though – so select_page, and every other tool that takes a pageId, can target a page list_pages never showed.

#2328 stopped that from silently stealing a still-open selection. This goes to the root: getPageById() now resolves through getPages(), so an unlisted page isn't targetable in the first place. Page ids only ever reach the client through the listing, so an unlisted id has no legitimate source. experimentalDevToolsDebugging is unaffected – the listing already includes devtools frontends there.

All five callers (select_page, close_page, evaluate_script, get_tab_id, and the generic pageId handler) benefit uniformly. Also trims the now-impossible example from the fallback comment – an unlisted devtools:// page can no longer be selected.

Test: with DevTools open, the frontend page is tracked but unlisted; the new test asserts no id outside getPages() resolves through getPageById().

Refs: #2304

[OrKoN]

Thanks for the PR. I think the existence of #pages and #mcpPages is rather and oversight and the root cause of this issue and I will fix it by refactoring the logic accordingly so this fix would not be needed.

[OrKoN]

I believe this would be addressed by #2333 but I think we can still land the test from this PR if you would be up to rebasing.

[thomasbachem]

Rebased. The refactor does simplify this a lot – after #2333 the fix is a one-liner. But the test still fails on current main without it: getPageById() searches all of #mcpPages, while getPages() – what list_pages shows – filters devtools:// frontends out. So an unlisted id still resolves, and a test-only PR would be red.

I've kept the minimal change of resolving through getPages() so the two agree and the test lands green – happy to drop it if you'd rather fold that into a follow-up.

[thomasbachem]

Thanks! Before I touch the approved branch: the red CI is two things, one of them mine.

macOS/Node 26: My new test was a second autoOpenDevTools test. Those share a cached browser (withBrowser keys on launch options) and close the previous test's pages on entry – tearing down the earlier devtools test's still-attaching DevTools target (the Target.attachToTarget unhandledRejection). Couldn't repro locally in 40 runs, but the race is there in every run – it just needs unlucky timing. Fixed by folding my assertions into the existing devtools test – with a single autoOpenDevTools test, nothing closes its pages mid-run.

Windows/Node 22: Unrelated timing flakes (exits within budget on stdin EOF, emulates viewport) – same class as the timeouts on main's last two runs.

Rebased onto latest main as well. OK to force-push over your approval?

[thomasbachem]

Pushed the test fold from my comment above on top of your rebase – one autoOpenDevTools test again, so the teardown race from the macOS run can't recur.