Enhance mm_get_context to expose mockServer state in e2e

Summary

mm_get_context currently reports capability presence (e.g., mockServer) but does not expose whether the mock server is actually enabled/running. This is causing agent/operator confusion in e2e flows where mock server is opt-in.

Problem

In e2e, the mock server capability may be available while still disabled by default. From the client side, mm_get_context does not provide enough signal to distinguish:

• capability exists
• capability enabled by config
• capability currently running

This makes it hard to reliably reason about whether network mocks are active.

Proposal

For e2e context, extend mm_get_context output to include explicit mock server state, for example:

{
  "currentContext": "e2e",
  "capabilities": {
    "mockServer": {
      "available": true,
      "enabled": false,
      "running": false,
      "port": 8000
    }
  }
}

For prod context (which has no mock server capability), return either:

• no mockServer field, or
• mockServer: { "available": false }

Why this helps

• Removes ambiguity between capability presence vs actual active state
• Improves agent ergonomics and deterministic automation flows
• Makes debugging easier when mocks are expected but not enabled

Acceptance criteria

• mm_get_context in e2e includes mock server state (available, enabled, running, and port if known)
• mm_get_context in prod clearly indicates mock server is unavailable
• Documentation/examples updated to reflect the new response shape

Start by locating the mm_get_context implementation and its e2e and prod response handling, then inspect the existing documentation and examples for the current response shape. Define the mockServer fields from the issue, update both context responses and the documentation, and verify that e2e reports state while prod clearly reports unavailability.