test(smoke): smoke.ts only boots the unified server, the four sub-MCPs are never started

[BryanFRD]

Problem

scripts/smoke.ts boots exactly one server:

const SERVER_ENTRY = resolve(__dirname, '..', 'packages', 'mcp', 'dist', 'index.js');

and asserts a fixed tool list against it (get_stats, health_check, fetch_docs, get_me, list_tokens, list_orgs, list_projects, list_vaults, list_issues, list_subscriptions).

@ferrlabs/mcp-vault, @ferrlabs/mcp-track, @ferrlabs/mcp-growth, and @ferrlabs/mcp-fleet are never started. Four of the six published binaries have no check that they even survive initialize.

Why it matters

The sub-MCPs are where the destructive surface lives (delete_vault, delete_secret, rotate_secret, trigger_agent_run, activate_release) and where the per-product base URL resolution happens (packages/mcp-*/src/api-base.ts) — the exact area #146 had to fix once already. A broken import, a bad dist entry, or a registration that throws at startup ships to npm undetected. #160 covers unit tests for the tool bodies; this is the cheaper complementary check that each binary boots and advertises the tools it claims.

Proposed approach

• Parameterise the smoke runner over the package list instead of hardcoding one entry path.
• Per server: initialize, assert serverInfo.name, tools/list, assert the expected tool names are present.
• Keep the live tools/call checks (health_check, get_stats) on the unified server only — the sub-MCP tools all need auth and a real backend.
• Run it for all six in the same CI step that runs it today.

Acceptance criteria

• pnpm smoke boots all six servers and fails if any one does not complete initialize or is missing an expected tool.
• Adding a new sub-MCP means adding one entry to a list, not copying the script.