fix: start nanobot with --config and publish only WordPress tools

[cjellick]

Problem

Since #9 switched the base image to ghcr.io/obot-platform/nanobot:v0.0.91, the container exits immediately on startup:

unknown command "/nanobot.yaml" for "nanobot run"

In nanobot v0.0.91, run is declared with cobra.NoArgs and only takes the config path through --config/-c. The Dockerfile CMD still passed /nanobot.yaml as a positional argument.

This went unnoticed because every "Build and Push Docker Image" run since #9 has failed. The image push succeeds, and the run fails later at the Trivy "Enforce vulnerability policy" step. The image pushed by #12's build (digest sha256:03a3f2d1…) is now running in our main environment, where the WordPress MCP server is in CrashLoopBackOff. :latest (v0.1.1) predates #9, so the default catalog is not affected yet, but the next release tag would ship the broken image.

A second problem showed up once the server started. Unless --disable-ui is passed, nanobot v0.0.91 merges its UI config into the published MCP server (pkg/config/static.go, pkg/cli/root.go). That adds these tools beside the WordPress tools: uploadFile, deleteFile, publishArtifact, installArtifact, deleteWorkflow, the five scheduled-task tools, and chat-with-nanobot (from the built-in agents).

Fix

• Pass the config with --config /nanobot.yaml.
• Add --disable-ui and --exclude-built-in-agents, so the server publishes only the WordPress tools.

Testing

Standalone container:

• The published image (03a3f2d1…) with the old arguments exits right away with the error above.
• With the new arguments, the server starts and tools/list returns exactly the 20 WordPress tools.

End to end through Obot: I ran a local ghcr.io/obot-platform/obot:main with the Docker backend, plus a local WordPress (MariaDB) with an application password. I used the default catalog's WordPress entry with only the image swapped, wrapped it in a personal vMCP, then created an instance, configured it, and launched it.

• Broken image (03a3f2d1…): POST /api/vmcps/{id}/launch returns 500 with failed to launch component MCP server …: failed to connect MCP client: calling "initialize": failed to ensure server is deployed: … container repeatedly crashed (exit code 1). This is the error seen on main, and the container log shows unknown command "/nanobot.yaml".
• Image built from this branch: launch returns 200, and GET /api/vmcps/{id}/tools lists only the 20 WordPress tools. Through /mcp-connect/{instance}, initialize and tools/list succeed. get_me returns the WordPress admin user, and list_posts returns the post I created.

Not addressed here

The workflow will still fail at "Enforce vulnerability policy". All of the HIGH findings are in the nanobot:v0.0.91 base image (Alpine busybox/openssl/wget, and the Go stdlib, grpc, and x/text/x/image in the nanobot binary). The latest nanobot release, v0.0.92, predates those fixes, so clearing them needs a new nanobot release.