feat(client): add credentials: 'include' toggle for cookie-auth servers

[SarthakB11]

Title: feat(web): add "Send cookies" toggle for direct Streamable HTTP connections (closes #1454)

Closes #1454.

Summary

Adds a "Send cookies (credentials: include)" checkbox to the connection settings
panel. When enabled, the direct transport passes credentials: 'include' on its
fetch calls so the browser attaches cookies stored for the target origin. Feature is default-off and follows the same UI+localStorage pattern used in the recently-merged connection-settings additions (#1553, #1551).

The browser treats Cookie as a forbidden header, so JavaScript cannot set it
manually. credentials: 'include' is the only standards-compliant way to send
cookies on a cross-origin request. Without it, MCP servers that rely on
cookie-based auth or session routing are unreachable from the inspector UI
unless the built bundle is patched by hand.

Changes

• New checkbox in the Sidebar connection settings, shown only when Connection
  Type is Direct (the option does not apply to the proxy transport, which
  forwards cookies server-side).
• credentialsInclude plumbed through App into useConnection; both direct
  fetch call sites (SSE and Streamable HTTP) add credentials: 'include' only
  when the toggle is on.
• State persists across sessions in localStorage under lastCredentialsInclude,
  matching the existing lastConnectionType persistence.
• Tooltip notes the server-side requirements: Access-Control-Allow-Credentials: true, a non-wildcard Access-Control-Allow-Origin, and SameSite=None; Secure for cross-site cookies.

Behavior

• Default: off. Fetch behavior is unchanged from today.
• On: credentials: 'include' is added to the direct-connection fetch
  options.

Acceptance criteria

• Toggle present in the connection settings UI for the Streamable HTTP
  transport.
• Off leaves fetch behavior unchanged.
• On passes credentials: 'include' to both direct-connection fetch sites.
• Toggle state persists via localStorage.
• Tooltip explains the required CORS response headers.

Test plan

• npm test (client) passes; added two useConnection tests covering the enabled and unset cases for the direct transport
• tsc --noEmit, eslint, and prettier --check clean on the changed files
• Manual smoke: point inspector at a cookie-authenticated MCP server with the toggle on, confirm Cookie header sent and session established (screenshot / GIF happy to add on request)

[SarthakB11]

This follows the same connection-settings pattern as #1551/#1553 (both merged recently): a scoped, default-off toggle, not a V2-scope change. Happy to add the manual-smoke screenshot if that would help move review along.

[cliffhall]

Closing: reviewed and declined on security grounds.

Thank you for this contribution, and apologies for the long wait for a response.

This PR was included in a security review of the full v1 backlog before bulk-closing it (#1819). Unlike most of that backlog — which is closed simply because v1 is deprecated — this change was read closely and is being declined on its merits: as written, it would weaken a security control the Inspector's threat model depends on.

Specifically: a credentials: 'include' toggle allows browser cookies to be sent to arbitrary direct targets. It is default-off, but it adds a new risk surface.

The Inspector's backend spawns local processes and proxies outbound requests on the developer's behalf, so it defends in layers: session-token auth, origin validation, loopback-only binding, and an SSRF block-list on the proxy. A change that removes or widens any one of those is a net loss even when it fixes a real usability problem — and several PRs in this group were framed as fixes or improvements, which is exactly why we're recording the decision explicitly rather than closing silently.

We're labeling this closed-v1-security-declined so the decision is queryable and doesn't get re-proposed against v2 later. This is not an accusation of bad intent — in most cases the security consequence was a side effect of an unrelated goal.

If the underlying need is real, we'd like to solve it in a way that preserves those controls. Please open an issue against v2 describing the problem you hit (not the patch), and we'll look at it. Note that we accept external contributions as issues rather than pull requests — see CONTRIBUTORS.md.