Include the CDP `targetId` in `list_pages` output

Is your feature request related to a problem? Please describe.

I run a thin stdio proxy in front of chrome-devtools-mcp that keeps page ids stable across restarts of the browser it drives (a dev app that gets re-exec'd at the same CDP port). The server reconnects fine on 1.6.0 and #2345 keeps ids unique, but a tab still gets a new id after a restart, so the proxy rewrites list_pages to hold one id per tab.

To do that it has to map each list_pages entry back to its CDP target, and there's no shared id to join on – list_pages gives title and url but not the CDP targetId. So the proxy fetches GET /json on the side and matches each entry by title, then url (consume-once). It's the most fragile thing the proxy does. Tabs that share a url are separable only by title – several of my tabs render the identical data: loader – so when titles also collide the match comes down to positional luck. And it's a second, independent read of browser state, so a tab opening or navigating between the /json fetch and the server's own view throws the listing off.

Describe the solution you'd like

Put each page's CDP targetId in list_pages output – ideally a field on the structuredContent.pages[] entries (and/or the text line). Then the mapping is just entry.targetId, with no /json round-trip to match up.

It's already on hand server-side (PageCollector reads it per page today), so it's a one-field addition to createStructuredPage() that leaves the existing fields alone – same shape as #2156, which added title. Happy to send the PR.

Describe alternatives you've considered

• Keeping the GET /json + title/url heuristic – works today, but is the fragile part above
• Reading the id client-side some other way – nothing in the MCP output keys on the CDP target, so it still means re-reading /json (or opening a separate CDP session) and re-matching, with the same fragility and a second source of truth to keep in sync

Additional context

targetId is stable per tab within a session and renews when the browser process restarts, same lifecycle as the underlying CDP id – I'm only after exposing it, not changing that.

Related: #2156 (added title), #2345 (unique ids across reconnects), #2304 (stale-listing selection retarget).

Start with PageCollector and createStructuredPage(), which the issue identifies as the existing server-side path for assembling list_pages entries. Add targetId to the structuredContent.pages[] output while preserving the current fields, then verify that list_pages exposes the CDP target ID for each page without requiring a separate /json lookup.