Feature request: Support incognito/isolated browser contexts in new_page tool

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

Feature Request

Summary

Add support for opening incognito (private) browser windows via the new_page tool,
either as a parameter (incognito: true) or via a dedicated tool.

Describe the solution you'd like

Proposed Solution

• Add an incognito: boolean parameter to new_page
• Or a --incognito CLI flag that launches Chrome in incognito mode by default
• Alternatively, support launching a second Chrome instance via --browser-url with
  a user-data-dir that has no cached NTLM tokens

Describe alternatives you've considered

Motivation

The current isolatedContext parameter creates isolated browser contexts within the
same Chrome process, which is useful for cookie/storage isolation. However, it does not
help when testing applications that use Windows Integrated Authentication (NTLM/Kerberos).

In Windows Auth applications, credentials are resolved at the OS level (SSPI), so
isolated contexts still pass through the same Windows identity. A true incognito window
(separate process, separate credential cache) would allow agents to test the app as
a different Windows user — extremely useful in Windows Authentication Applications.

Additional context

Use Case

Testing role-based access control in ASP.NET Core Blazor Server apps with Windows
Authentication, where different AD group memberships result in different UI behavior.
Currently impossible to test multiple user roles via DT-MCP in the same session.

Start with the new_page tool and its isolatedContext parameter, then trace how --browser-url and Chrome launch options are handled. Compare the proposed incognito parameter, --incognito flag, and separate user-data-dir approach against the NTLM/Kerberos use case. Done means one supported approach is implemented with coverage for isolated credentials and the documented entry point.