fix(053): drop duplicate MCP registry workflow; point docs at existing release.yml job (#518)

release.yml already has an 'mcp-registry' job that publishes server.json on every
tag via keyless GitHub OIDC (continue-on-error) — it has shipped 44 versions to
registry.modelcontextprotocol.io. The publish-mcp-registry.yml added in #517 was a
redundant duplicate that would have thrown 'cannot publish duplicate version' on
every release. Removes it and corrects docs/mcp-registry-publishing.md to reference
the existing automation instead of claiming publishing was manual.

Author: Dumbris

.github/workflows/publish-mcp-registry.yml

@@ -2,7 +2,7 @@
 
 This guide covers how to publish (or update) the `server.json` at the repo root to the official [MCP Registry](https://registry.modelcontextprotocol.io).
 
-**Publishing is automated.** The [`.github/workflows/publish-mcp-registry.yml`](../.github/workflows/publish-mcp-registry.yml) workflow publishes `server.json` on every GitHub Release using keyless GitHub OIDC auth — no stored token or secret. It syncs `server.json`'s `version` to the release tag at publish time, so you don't need to hand-bump it. The manual steps below remain useful for first-time setup, validation, ad-hoc `workflow_dispatch` runs, and deprecating versions.
+**Publishing is already automated** by the `mcp-registry` job in [`.github/workflows/release.yml`](../.github/workflows/release.yml). On every tag/release it authenticates with keyless GitHub OIDC (no stored token/secret), syncs `server.json`'s `version` to the release tag, and publishes — so you never hand-publish a release. The job is `continue-on-error: true`, so a duplicate-version push (the registry stores versions immutably) won't fail the release. The manual steps below remain useful for first-time setup, local validation, and deprecating versions.
 
 ## Prerequisites
 
@@ -92,8 +92,8 @@ mcp-publisher status --status deleted \
 
 ## What Requires the User
 
-- **GitHub authentication**: Only a member/owner of the `smart-mcp-proxy` GitHub org can authenticate for the `io.github.smart-mcp-proxy` namespace. There is no way to delegate or automate this without adding a GitHub Actions workflow with `id-token: write` permission to the release pipeline.
-- **Automating via CI** (done): [`.github/workflows/publish-mcp-registry.yml`](../.github/workflows/publish-mcp-registry.yml) runs `mcp-publisher login github-oidc` + `mcp-publisher publish` on `release: published` (and via manual `workflow_dispatch`). It declares `id-token: write`, downloads the pinned `mcp-publisher` binary, syncs `version` from the release tag, validates, then publishes. The OIDC token is minted per run and valid only for that run — no secret is stored. The first run must succeed as a member identity of the `smart-mcp-proxy` org (the workflow's repo identity satisfies this).
+- **Nothing, for the normal release path.** The `mcp-registry` job in [`.github/workflows/release.yml`](../.github/workflows/release.yml) already runs `mcp-publisher login github-oidc` + `mcp-publisher publish` on every tag (`id-token: write`, `continue-on-error: true`). The workflow's repo OIDC identity proves `smart-mcp-proxy` org membership, which owns the `io.github.smart-mcp-proxy` namespace — no secret or interactive login is involved.
+- **Manual interactive login** (`mcp-publisher login github`) is only needed for out-of-band actions: validating locally, deprecating/deleting a published version, or a one-off re-publish. Note its browser-issued token is short-lived and expires quickly.
 
 ## Registry Schema Notes