ci: docs-gate companion so docs-only PRs satisfy required checks (no admin bypass)

[mcp-tool-shop]

Problem — a CI/branch-protection deadlock blocks docs-only PRs

main branch protection requires these status checks before merge:

lint-and-test
validate-templates (app)
validate-templates (default)
validate-templates (docs)
validate-templates (portfolio)
validate-templates (product)

Those contexts are produced by ci.yml, which is paths-gated to code paths (package.json, package-lock.json, cli/**, components/**, types/**, templates/**, styles/**, tests/**, tsconfig.json, .github/workflows/**).

A PR that changes only README*.md (e.g. the per-release translations refresh) never matches those paths, so ci.yml never runs and the required checks never report. The PR sits MERGEABLE / BLOCKED forever — the required check is stuck Pending. Every release has had to bypass this with an admin merge (--admin). It happened on the v2.1.0 translations PR (#17).

Fix — GitHub's documented "skipped but required checks" pattern

Add a tiny companion workflow .github/workflows/ci-docs.yml that:

• triggers on the inverse paths (paths-ignore == ci.yml's paths), so it runs only when a PR changes no code paths;
• defines no-op jobs whose names mirror the required contexts exactly — lint-and-test and a validate-templates matrix [default, docs, product, portfolio, app, tool] — each running a few-second echo.

On a docs-only PR the companion reports all required contexts green in seconds; ci.yml stays correctly skipped (no wasted build). On a code PR the companion stays out of the way and the real build is the only thing reporting the contexts.

Refs:

• https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/handling-skipped-but-required-checks
• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks

Why a separate file (not a job inside ci.yml)

paths is a workflow-level trigger filter — it gates the entire ci.yml. A no-op job added inside ci.yml would be gated by the same code-paths filter and would not run on docs-only PRs. The companion must be its own file with the inverse filter. It is intentionally minimal (no checkout, no setup-node, pure echo).

Safety — real code PRs are NOT weakened

PR touches	ci.yml (real build)	ci-docs.yml (no-op)	Result
code only	✅ runs	⛔ skipped	real build gates ✔
docs only (README*.md)	⛔ skipped	✅ runs	required checks report green ✔
mixed (code + docs)	✅ runs	✅ runs	both report the same contexts

For the mixed case, GitHub evaluates same-named required checks as a conjunction — per the docs, "if you have a check and a status with the same name … both … are required." All check runs sharing a context name must pass, so a failing real build still blocks the merge; the no-op can never shadow it. It fails closed. Protection on real code changes is unchanged: the full lint-and-test + validate-templates still gate any PR that touches code.

Org GitHub Actions rules — respected

• Real build (ci.yml) stays paths-gated; this companion is also paths-filtered (inverse).
• ubuntu-latest.
• Existing concurrency block preserved (and present here).
• workflow_dispatch manual fallback included.
• One small new file — needed because ci.yml's path filter is workflow-level (see above).

Verification

• This PR changes .github/workflows/**, which is a code path → it triggers the real ci.yml (full lint-and-test + validate-templates matrix) and does not trigger the companion. That confirms code/workflow PRs still run the full build.
• A README-only PR (simulated against this branch) triggers the companion's lint-and-test + validate-templates (*) checks, which report green, and ci.yml is skipped — so the PR becomes mergeable through the normal flow with no --admin. (Final confirmation lands once this is on main: the next translations PR will go green on its own.)

This pattern may recur on other org repos

Any mcp-tool-shop-org repo that combines required status checks with a paths-gated CI workflow has the same latent deadlock for docs-only PRs. This PR is scoped to site-theme only; flagging for awareness so the same companion-workflow fix can be applied where the pattern repeats (e.g. registry-stats and other Astro/CI repos).