Add optional HTTP transport with persistent per-user API key authentication

[Ricciolo]

Problem

When TwinCAT runs inside a Windows VM and the MCP client/agent runs on macOS, the current stdio transport configured in .mcp.json cannot cross the host/VM boundary because the client and server must run on the same machine. This prevents agents on the host from using the PLC-aware TwinCAT tooling in the VM without building a separate bridge or wrapper.

Proposed Solution

Add an optional HTTP transport to TwinCat.Xae.Mcp.Server.exe:

TwinCat.Xae.Mcp.Server.exe --http --port 8080

This exposes the server as a remote MCP endpoint over HTTP/HTTPS while preserving the existing stdio transport as the default/optional mode.

Authentication Design

To enable secure remote access without requiring manual key management:

• Auto-generate a persistent per-user API key on first application run.
• Store the key in user-protected configuration storage (e.g., %APPDATA%\TechIndustryX\TwinCAT\mcp-server-api-key on Windows).
• Reuse the same key indefinitely across application launches—no expiration or rotation unless explicitly reset by the user.
• Never require manual key configuration or command-line arguments—key is managed entirely by the application.
• Accept the key only via the Authorization: Bearer <api-key> HTTP header—not query parameters or other methods.
• Use constant-time comparison when validating credentials.
• Never log or expose the key in error messages, diagnostics, or responses.

Security & Defaults

• Default binding: 127.0.0.1 (localhost only).
• Remote interfaces: Require HTTPS when binding to non-loopback addresses.
• Error responses: Return 401 Unauthorized for missing or invalid credentials; do not distinguish between "missing" and "invalid" in the response body.
• Preserved behavior: Existing stdio transport remains unchanged.
• Graceful error handling:
  • First-run key file creation (atomic writes, proper permissions).
  • Missing or unreadable key file (clear diagnostic, suggestion to regenerate).
  • Port binding failures (clear diagnostics, port availability check).
  • Connection timeouts and session lifecycle over HTTP.

Acceptance Criteria

• Command-line flag --http enables HTTP mode; --port <N> configures the listening port.
• API key is generated automatically on first run and stored securely in user configuration storage.
• User is shown the API key once at first startup (e.g., in console output) or via a diagnostic command (e.g., --show-api-key).
• Long-running operations such as session_build work correctly over HTTP without timeouts or connection drops.
• Clear, actionable diagnostics for startup errors, port conflicts, and connection failures.
• Documentation covers key management: viewing the current key, regenerating a new key, and securing the key file.
• Behavior is testable by connecting an MCP client from macOS to a Windows VM running the server.
• All existing stdio-based workflows remain unaffected.
• Startup explicitly warns if HTTP is enabled on a non-loopback interface without HTTPS.

Additional Context

• The shipped binary appears to include ASP.NET Core MCP hosting components (Kestrel, WithHttpTransport, MapMcp), suggesting that enabling HTTP mode may require relatively modest implementation effort.
• The requester has a real-world test environment (macOS + Windows VM) and has offered to validate the implementation.
• This feature unblocks cross-platform agent workflows without requiring third-party proxy or bridge software.