fix: keep page ids unique across browser reconnects

[thomasbachem]

Closes #2339

Reconnecting after a browser restart builds a fresh McpContext, which restarted the page id counter at 1 – ids from before the restart silently resolved to unrelated pages of the new browser (repro in #2339).

Two changes:

• The new context continues the id counter where the previous one left off (startingPageId option), so a stale id now fails with the existing "No page found" error and the agent re-lists
• The first response after a reconnect carries a one-time note ("the browser was restarted or reconnected since the last call. Page ids have changed..."), like the fix: report when the selected page was auto-replaced by the fallback #2308 fallback note. Since tool errors run through the same response formatting, the note shows up together with the very error the stale id produces

Verified against the #2339 repro: the stale select_page now returns the note plus "No page found", and the next listing shows the new browser's pages under fresh ids.

One thing I noticed but left alone: The replaced context isn't dispose()d on reconnect – pre-existing, and everything it holds is tied to the dead browser anyway. Happy to add that here if you'd like.

[OrKoN]

Thanks, I think it is a good idea to add this. I have left a few comments.

[thomasbachem]

Thanks – all five applied. Two notes:

• nextPageId never resets now, so ids stay unique across all contexts in the process. Tests keep numbering from 1 via a resetPageIdsForTesting() called in the withMcpContext fixture.
• On the id test: The page-to-id map is per-context, so the same page gets a fresh id in a new context. The test therefore asserts a stale id no longer resolves and new ids continue past it – asserting "same page, same id" literally would need the map at module level too. Happy to do that if that's the semantics you want.

[OrKoN]

Thanks!