e2e + mockServer proxy can break HTTPS dapp navigation due TLS trust/cert validation

## Summary
When running in `e2e` context with `mockServer.enabled=true`, HTTPS dapps (e.g. `https://metamask.github.io/test-dapp/`) can fail to load because all traffic is routed through the mock proxy and TLS validation/certificate trust breaks in practice.

This makes `mockServer` mode unreliable for workflows that need to open real HTTPS dapps while still mocking selected APIs.

## Why this is relevant to client-mcp-core
`client-mcp-core` defines and forwards context configuration (`mm_set_context` -> `setContext(context, options)`) and exposes context metadata (`mm_get_context`), so this is the right place to define safer/clearer proxy-mode semantics and expected behavior.

## Observed behavior
- Context is set to e2e with mock server enabled.
- Launch succeeds, but navigating to HTTPS dapps may fail with certificate/SSL-style errors.
- In this mode, operator expectation is usually: "mock specific endpoints, but still open normal HTTPS dapps".

## Reproduction
1. `mm_cleanup`
2. `mm_set_context { "context": "e2e", "options": { "mockServer": { "enabled": true, "port": 8000 } } }`
3. `mm_launch { "stateMode": "default" }`
4. `mm_navigate { "screen": "url", "url": "https://metamask.github.io/test-dapp/" }`
5. Observe TLS/cert failures or inability to load the dapp in some runs/environments.

## Local research notes
### In client-mcp-core
- `mm_set_context` forwards `options` transparently to the session manager (`src/mcp-server/tools/context.ts`).
- `ISessionManager.setContext(context, options)` and `getContextInfo()` are generic and currently expose capability availability, not operational proxy/TLS status (`src/mcp-server/session-manager.ts`).

### In MetaMask extension consumer implementation (where issue manifests)
- Mock server starts and, when running, its host:port is passed as browser proxy.
- Browser launch uses proxy args and `ignoreHTTPSErrors` when proxy is set.
- Mock server uses HTTPS via generated CA cert.
- This combination means HTTPS trust behavior is critical and can still fail depending on proxy mode / cert trust path.

## External context
- Playwright `ignoreHTTPSErrors` is not always sufficient for all proxy-intercept TLS scenarios.
- Mockttp HTTPS interception requires proper CA trust strategy.

## Proposal
Introduce explicit proxy/TLS mode semantics at the API level (even if implemented by consumers):

1. Add explicit proxy mode concept for e2e context options:
- `proxyMode: "tunnel" | "mitm"` (or equivalent)
- Default should favor safer/more compatible behavior for opening normal HTTPS dapps.
2. Document expected TLS trust requirements for MITM mode.
3. Extend `mm_get_context` to surface operational proxy/mock TLS state (not only capability presence), e.g. whether mock server is enabled/running and effective proxy mode.
4. Clarify recommended behavior for mixed usage: "mock API X but still navigate to arbitrary HTTPS dapps".

## Acceptance criteria
- Clear documented behavior for HTTPS navigation under `mockServer.enabled=true`.
- Deterministic way to run e2e with mock server and still open HTTPS dapps.
- Context/status APIs expose enough runtime state to diagnose this quickly.

## Additional note
I already opened a related issue to improve `mm_get_context` state visibility:
- https://github.com/MetaMask/client-mcp-core/issues/13

Start by reading src/mcp-server/tools/context.ts and src/mcp-server/session-manager.ts to trace how mm_set_context forwards options and how mm_get_context reports state. Compare that API with the documented proxy, TLS, and HTTPS-navigation requirements, and review related issue #13. Done means the behavior is documented, HTTPS dapp navigation is deterministic with mockServer enabled, and context status exposes enough runtime information to diagnose failures.

Written by the indexing model from the issue text.