fix: gate MCP server actions behind isMcpEnabled

[aroh3006]

Fixes #6757.

app/mcp/actions.ts has "use server" at the top, which makes every
exported function in the file callable directly over HTTP as a Next.js
Server Action, unauthenticated, using the action id embedded in the
client bundle. isMcpEnabled() already existed as a guard for this,
but nothing called it, so every action ran regardless of the
ENABLE_MCP setting.

addMcpServer writes a caller-supplied {command, args} to
mcp_config.json and spawns a child process with them via
StdioClientTransport. With no auth check and no isMcpEnabled()
check, that's remote code execution reachable on any deployment,
whether or not MCP was ever turned on — exactly as laid out in #6757.

Every exported action in the file now calls isMcpEnabled() first and
rejects if it's off. This matches what the frontend already does —
chat.tsx, home.tsx, mcp-market.tsx, sidebar.tsx and
store/chat.ts all check isMcpEnabled() before ever calling these,
so legitimate MCP usage (ENABLE_MCP=true) is unaffected.

Test. Added test/mcp-actions-require-enabled.test.ts, which calls
every exported action with ENABLE_MCP unset and asserts each one
rejects with "MCP is not enabled" instead of running, plus a couple of
sanity checks for the enabled case. Ran it against the current code
first: addMcpServer actually wrote the malicious config to disk and
spawned the process — a real file was created on my machine by the
touch payload in the test, running against unpatched main. It
fails there and passes with this change.

This only closes the primary path in #6757 (no auth check at all). The
report's other recommendations — command allowlisting, not inheriting
the full process.env into the spawned process, and moving MCP
management to an explicit authenticated route — are broader hardening
for deployments that do have ENABLE_MCP=true, and probably deserve
their own separate PR(s) and maintainer input on the intended design.