mcp: flow mcp serve can never learn about plugins — the remote agent surface is permanently blind to plugin tasks and does not say so

Problem

flow mcp (stdio) is plugin-aware: addPluginFlags(mcpCmd) at cmd/flow/main.go:3184, with the comment above it recording that worker, server, plugins and lsp all do the same. Its deployable sibling flow mcp serve — the OAuth-protected HTTP surface built for remote agents (docs/MCP_AUTHORIZATION.md) — is not: addPluginFlags attaches local flags to the parent command only, mcpServeCmd gets addMCPServeFlags alone, and runMCPServe (cmd/flow/mcpserve.go) never calls startPlugins or loadPluginCatalog (grep: the file's only "plugin" hits are prose). There is no flag and no environment variable an operator can set.

Consequence: every remote agent connecting to flow mcp serve gets no plugin task "x" is registered here from flowstate_validate and a plugin-free answer from flowstate_get_catalog, permanently, on exactly the deployments where plugins are the expected shape (docs/DEPLOYMENT.md, docs/PLUGINS.md). Neither tool's description on this surface discloses the limitation, so the agent has no way to distinguish "this deployment has no plugins" from "this surface cannot see them" — the confident wrong answer, on the surface most exposed to callers who cannot inspect the process.

Desired outcome

Both halves: flow mcp serve gains the plugin wiring (at minimum --plugin-catalog, which launches nothing and fits a serving process better than exec'ing binaries per request; --plugin-dir is a separate judgment since this surface faces the network), and until/unless that lands, the Validate/GetCatalog tool notes on this surface state the blindness so an agent's wrong answer at least announces itself.

Acceptance

• A deployment can start flow mcp serve such that flowstate_validate accepts and flowstate_get_catalog lists the deployment's plugin tasks, proven by a test on the serve path (today mcpserve_test.go has zero plugin references).
• The tool descriptions on this surface accurately describe what the answers do and do not cover.

Adjacency

#1288/#1289/#1290 are MCP defects on other axes (schema size, stdin fragility, argument shape) — none touch plugins. #1294 covers flowstate_test's inherited flowtest blindness; validate/get_catalog here go through a different path. The stdio flow mcp side was fixed by the #710-era sweep; this is its deployed sibling. Filed separately from the schedule/compile/dap flag omissions because a network-facing serving process raises questions (exec-per-request, catalog staleness) those local verbs do not.

Start with cmd/flow/main.go around addPluginFlags, cmd/flow/mcpserve.go, and mcpserve_test.go; compare the serve path with the stdio MCP path and read docs/MCP_AUTHORIZATION.md, docs/DEPLOYMENT.md, and docs/PLUGINS.md. Determine the safe serving-process plugin wiring, then add a serve-path test proving plugin tasks appear in Validate and GetCatalog and verify the tool notes accurately state the surface's coverage.