[FEATURE] Add scan-scoped MCP tool support

[vietvan431]

Problem

Strix scan agents currently have a fixed built-in tool set. Users cannot safely connect their own MCP servers for capabilities such as security-data lookup, ticketing, or finding management without adding first-party integrations.

MCP servers run with host permissions, so simply loading every discovered server or tool would create an unsafe trust boundary.

Proposed solution

Add scan-scoped support for consuming user-configured MCP servers:

• Discover definitions from ~/.strix/.mcp.json and project .mcp.json files.
• Keep definitions disabled until the user explicitly enables a server and
  selects allowed tools.
• Bind approval to the definition source and fingerprint so changed, moved, or
  shadowed definitions require review and re-enablement.
• Support stdio, SSE, and Streamable HTTP transports with environment-variable
  expansion, connection timeouts, tool-call timeouts, and cleanup.
• Support allow/deny glob filters and root-agent-only tools.
• Provide strix mcp list|enable|disable|test management commands.
• Provide --no-mcp for hermetic and CI scans.
• Bound large tool responses and keep the Go TUI usable by collapsing long MCP
  output.
• Document the host-side trust model and configuration workflow.

Acceptance criteria

• Adding a definition alone never starts or exposes an MCP server.
• Only explicitly enabled and unchanged definitions connect at scan start.
• Only allowed, non-denied tools are exposed to agents.
• Project definitions safely shadow user definitions by server name.
• Missing or changed enabled definitions fail safely and explain how to
  revoke or re-enable them.
• MCP processes and sessions are cleaned up on completion, failure, and
  cancellation.
• Tool output respects Strix context limits and long TUI output is collapsed
  by default.
• Unit and integration tests cover discovery, trust checks, transports,
  output handling, cancellation, and agent registration.
• User documentation explains setup, management commands, and security
  implications.

This is distinct from #698: that proposal exposes Strix capabilities to an external coding-agent runtime, while this issue allows Strix's existing agents to consume user-provided MCP tools.