Add a Grok Build harness

[CrypticSwarm]

Adds xAI's Grok Build CLI as a third harness, alongside OpenCode and Claude Code.

What's here

build_grok / run_grok / update_grok / stop_grok. The image installs the official CLI via x.ai/cli/install.sh in a grok AGENT branch and relocates the binary to /usr/local/bin/grok, dropping the root-side ~/.grok so the runtime config dir stays credential-only.

Persistent credentialed home, the Claude pattern. $(GROK_HOME_DIR) mounts at /home/anvil and keeps ~/.grok/ across runs. ~/.grok/skills and ~/.grok/commands are tmpfs masks over it, so the entrypoint repopulates them per run and per-repo assets never accumulate in the persistent home or leak between repos.

MCP tongs. A session with an mcp-interface tong previously refused to launch under run_grok, because no MCP emitter existed for the harness. The discovered servers are now emitted in Grok's native TOML shape — [mcp_servers.<name>], where a url key is what selects the remote transport — and delivered through the existing SWARMFORGE_TONG_MCP_FILE mount.

Grok's config dest is its persistent home rather than a directory rebuilt each run, so swarmforge/config/merge_grok_mcp.py keeps the generated servers in a sentinel-delimited managed block: rewritten every run, stripped when a session has no MCP tongs, and yielding to a same-named server the user defines themselves (appending it would be a TOML duplicate-table error). The entrypoint's tong merge is now dispatched per harness, which also stops the fragment from landing in an opencode.json inside a non-OpenCode config dest.

Two renames this pulls in

CLAUDE_REPO_SLUG / CLAUDE_REMOTE_NAME become SWARMFORGE_REPO_SLUG / SWARMFORGE_REMOTE_NAME. Both persistent-home harnesses use them, and neither should have to name Claude to do it. No fallback from the old names — an override under one is silently ignored, as with the OPENCODE_UID/OPENCODE_GID drop.

OPENCODE_INSTALL_BUST and CLAUDE_INSTALL_BUST collapse into one SWARMFORGE_HARNESS_INSTALL_BUST (first commit, so the Grok work uses it rather than adding a third). A build target names both the stage and the agent it installs, so the value only ever reaches that one install step; a name per harness was restating the target, and every new harness added another. make update_opencode and make update_claude are unchanged from the outside.

Not in scope

Subagent definitions are not translated for Grok — the unified-agent pipeline still covers OpenCode and Claude only, and the entrypoint's prepare_unified_agents falls through for the harness. Skills and commands travel the shared asset pipeline as usual.