ci: build & push SMCP image from swiss-rockets

[taferh]

What

Adds .github/workflows/build-push-smcp.yml — builds the SMCP (compact-mode ToolUniverse-as-MCP) image from deploy/Dockerfile and pushes to registry.squirro.com/mcp/tooluniverse. Modeled on the house build workflow, kept as close as possible (same SHA pins, secret names, tag strategy, step order).

Triggers

Event	Action
push swiss-rockets	build + push (sha-<short>, swiss-rockets)
push tag v*.*.*	build + push (X.Y.Z, X.Y)
PR → swiss-rockets	build only (no login, no push)
push main	nothing

Three deltas from the house template

1. Build branch swiss-rockets, not main — main is a manual fork-sync mirror of mims-harvard:main (manual ≠ reviewed); it must never build a deployable image. Upstream reaches swiss-rockets only via a reviewed PR.
2. IMAGE_NAME → mcp/tooluniverse — overrides github.repository (= squirro/ToolUniverse, whose uppercase a Harbor path rejects).
3. Builds deploy/Dockerfile, not the root upstream Dockerfile.

Needs from the Squirro side

• Repo secrets HARBOR_USERNAME / HARBOR_PASSWORD (Harbor robot account).
• Branch protection on swiss-rockets (PR-only, no direct push) — the trusted-ref assumption rests on this.

Deploy-spec (FluxCD/CD half)

Field	Value
Image	registry.squirro.com/mcp/tooluniverse:<sha-… or X.Y.Z> — pin immutable
Port	8000 (--transport http --host 0.0.0.0 --port 8000)
Healthcheck	TCP connect :8000
Readiness	initialDelaySeconds ≈ 300 (compact mode loads ~2,278 tools at startup)
Memory	must clear the compact-mode load; Tool_RAG excluded so the 1.5B embedding model never loads — don't budget for it
Volume	PVC at /root/.tooluniverse (bulk TSVs, NCBI cache, downloaded refs)
Runtime env (k8s Secret)	OPENAI_API_KEY required (find_tools/Tool_Finder_LLM is OpenAI-backed); per-tool-family keys optional

No scan/SBOM step in CI by design — Harbor Trivy (image) + Aikido (deps) cover it.

Open questions

1. FluxCD memory request/limit for the compact-mode container?
2. Who repoints Squirro's Studio-UI MCP registration from 127.0.0.1:8765 to the in-cluster Service DNS?