feat: support initial connection type via query param and CLI flag

[marc-antoinejean-optable]

Summary

Adds an "initial connection type" configuration knob ("direct" or "proxy"), mirroring the existing transport / serverUrl plumbing already supported on main:

• ?connectionType=direct|proxy query param (URL-mode)
• --connection-type <direct|proxy> CLI flag, forwarded by client/bin/start.js
• defaultConnectionType field on the /config response, consumed by the client

Values are whitelisted to "direct" | "proxy" at every read site (getInitialConnectionType and the /config handler). Unknown values fall through to the previous behavior: localStorage.lastConnectionType, defaulting to "proxy" — so there is no behavior change unless a user opts in.

This is parity work, not a new concept: the same plumbing was added for transport / serverUrl in 7ea47c0.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Build/CI improvements

Changes Made

• server/src/index.ts: register --connection-type in parseArgs; expose defaultConnectionType on the /config response.
• client/bin/start.js: accept --connection-type CLI flag; forward as MCP_CONNECTION_TYPE env var in dev mode and as --connection-type=... arg in prod mode (matching the existing transport / serverUrl handling).
• client/src/utils/configUtils.ts: new getInitialConnectionType() helper — reads ?connectionType= query param, falls back to localStorage.lastConnectionType, defaults to "proxy".
• client/src/App.tsx: use getInitialConnectionType as the useState initializer; apply defaultConnectionType from /config when valid ("direct" | "proxy" only).
• README.md: document the new connectionType query param.
• Tests: see Testing section.

Related Issues

None found

Testing

• Tested in UI mode
• Tested in CLI mode
  • Didn't manage to get it to pick up the argument. Even with --transport or --server-url
• Tested with STDIO transport
  • N/A. connection-type doesn't apply
• Tested with SSE transport
• Tested with Streamable HTTP transport
• Added/updated automated tests
• Manual testing performed

Test Results and/or Instructions

1. Start the dev app with npm run dev
2. Navigate to http://localhost:6274/?connectionType=proxy or http://localhost:6274/?connectionType=direct and validate that the connection type is correctly switched to the correct value

Checklist

• Code follows the style guidelines (ran npm run prettier-fix)
• Self-review completed
• Code is commented where necessary
• Documentation updated (README, comments, etc.)

Breaking Changes

None

Additional Context

This is additive UX and not a strict bug fix or spec-compliance change, so I understand if it's deferred to V2. Framing the diff as a extension of an existing pattern (transport / serverUrl -> connectionType).