fix: resolve page ids only among listed pages

[thomasbachem]

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

getPageById() searches all of #mcpPages, which includes pages that #pages filters out of the listing – notably devtools:// frontends (present in browser.pages() via handleDevToolsAsPage, excluded from #pages unless experimentalDevToolsDebugging). 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 only among #pages, so an unlisted page isn't selectable in the first place. Page ids only ever reach the client through the listing, so an unlisted id has no legitimate source. Since #pages already includes devtools frontends when experimentalDevToolsDebugging is set, that mode is unaffected.

All five callers (select_page, close_page, evaluate_script, get_tab_id, and the generic pageId handler) benefit uniformly – they now operate strictly on the pages list_pages presents. Also trims the now-stale example from #2328's fallback comment, since an unlisted devtools:// page can no longer be selected.

Test: opening DevTools for a page yields a tracked-but-unlisted page; the new test asserts its id no longer 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.