fix: report the tab id in the get_tab_id response

[serhiizghama]

Follow-up to the get_tab_id side-thread in #2366. This doesn't look like a Puppeteer regression — I checked _tabId against the pinned puppeteer-core 25.3.0 on real Chrome (launch and connect, browser.pages(), pages(true), newPage(), with handleDevToolsAsPage: true) and it came back populated every time.

What actually happens is that the handler only calls response.setTabId(), so the id rides in structuredContent and nowhere else — and ToolHandler attaches structuredContent to the result only when --experimental-structured-content is set (ToolHandler.ts:287). The tool itself is gated behind --experimental-interop-tools, so turning on just the interop tools gives you an empty response for every page. src/bin/chrome-devtools.ts puts --experimentalStructuredContent in its default args, which is why it looks fine over the CLI but not when the server is driven over MCP.

That's also why it passes in our test: it stubs _tabId and calls response.handle() directly, skipping the handler where the gate lives, then asserts responseLines is empty — which pins the missing output as expected behaviour.

So the id now goes into the response text like every other tool, and setTabId stays for structured consumers. Reverting just the handler change fails the new test with expected the tab id in the response, got: and an empty string — the reported symptom. I also handled the empty string Puppeteer documents as "unknown" rather than emitting a bare Tab ID:.

pages suite is green (50 tests), ToolHandler suite too.

[Lightning00Blade]

You should be able to pass

withMcpContext(cb(), {
  experimentalInteropTools: true, 
  experimentalStructuredContent: false,
})

That will remove the need for the setup.

[serhiizghama]

Good call — dropped the ToolHandler setup and pass the flags through withMcpContext instead. Went with the third args param since that's where the ParsedArguments overrides land.

[Lightning00Blade]

Looks good with one comment for the test setup.