v1.8.2 — the MCP server moves into the package namespace

Fixed — co-installing two skills broke all but the last one

Every skill shipped its MCP server as a top-level mcp_server package. Python
has one top-level namespace, so installing any two of them into one environment let
the second overwrite the first — silently, with no error and no warning.

uv tool install vmware-aiops   ->  49 tools   (correct)
uv pip  install vmware-aiops   ->  27 tools   (Monitor's read-only server)

vmware-aiops depends on vmware-monitor, so this was not an edge case: every pip
install hit it, and the operator got 27 read-only tools where 49 were expected,
with all 35 write tools missing. Docker images, shared MCP hosts and CI runners that
install more than one skill were affected the same way.

The server now lives at vmware_<skill>/mcp_server/, a name only this package can
claim. Introduced 2026-02-26; it survived 70 releases because every test ran against
a single package in its own repo, where the local directory shadows site-packages —
the conflict was invisible by construction.

Migration. Console scripts are unchanged: vmware-<skill> and
vmware-<skill>-mcp work exactly as before, as does "command": "vmware-<skill>", "args": ["mcp"] in an MCP client config. Only a direct python -m mcp_server
breaks; use python -m vmware_<skill>.mcp_server.

Added — references/agent-guardrails.md in every skill

The operating rules for local and small models (Llama 3.3 70B, Qwen, Mistral via
Goose / Ollama / OpenShift AI) existed in two skills. They now ship in all 13, each
with its own tool counts and failure modes, and are linked from every SKILL.md.