feat: support \ without workspace.yaml mcpProxy config

[christso]

Summary

Add first-class proxy support to the allagents mcp add workflow so users can opt into mcp-remote directly from the CLI, without manually editing workspace.yaml to add mcpProxy:.

Example target UX:

allagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy

Optionally:

allagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy --client claude,codex,copilot

Motivation

Upstream allagents now has a dedicated mcp command surface, which is the right direction for MCP-only workflows. However, the current proxy path is still driven by workspace.yaml:

mcpProxy:
  clients:
    - claude
    - codex

That works, but it is not ergonomic for users who just want to add one server through the CLI and have it use the built-in mcp-remote rewrite immediately.

Today the user has to:

1. add the MCP server
2. edit workspace.yaml
3. add mcpProxy.clients or per-server overrides
4. sync again

For one-off installs, that is more ceremony than necessary.

Why this belongs on mcp add

I think this should be a flag on mcp add, not a separate mcp proxy command group.

allagents mcp add <name> <commandOrUrl> --proxy

Reasons:

• proxying is a transport/detail of the server definition, not a separate top-level object
• it composes naturally with existing flags like --client, --transport, --env, and --header
• it matches user intent: “add this MCP server, but proxy it”
• it avoids splitting similar workflows across mcp add and a separate proxy namespace

Proposed Behavior

mcp add --proxy

When --proxy is used with an HTTP server:

• the server should be added normally via mcp add
• the workspace config should record that this server should be proxied for the selected clients
• the built-in proxy rewrite should be applied during post-mutation sync
• the proxy metadata file should be created automatically if needed

Interaction with --client

If --client is present:

allagents mcp add ediprod https://ediprod.mcp.wtg.zone --proxy --client claude,codex

then proxying should apply only to those clients.

If --client is omitted, I would expect proxying to apply to all MCP-capable configured clients, same as the rest of mcp add behavior.

Config representation

Internally, this can still persist to workspace.yaml via the existing mcpProxy structure. The point is not to avoid persistence — it is to avoid requiring the user to hand-edit that structure.

In other words, this issue is about CLI ergonomics, not changing the config model.

Acceptance Criteria

• allagents mcp add <name> <url> --proxy works for HTTP MCP servers
• --proxy automatically enables the existing mcp-remote rewrite path
• proxy metadata file is created automatically when needed
• --proxy --client claude,codex scopes proxying to those clients
• no manual workspace.yaml edit is required for the common case
• help/docs explain that this uses the existing mcp-remote-based proxy implementation

Related Context

• Existing MCP subcommand issue: feat: mcp subcommand for managing MCP servers independently #346
• Existing proxy implementation already exists in src/core/mcp-proxy.ts
• Current capability is strong, but the CLI path is still more manual than it needs to be

Example Use Case

Enterprise/internal MCP servers like ediprod and wtgkb often work best through a local proxy for clients that struggle with HTTP auth or OAuth callback flows. allagents already has the machinery for this via mcp-remote; this request is to expose that path directly in the command users already expect to use.