chore(registry): realign server.json to 0.4.114, add publish step to release workflow

The official MCP Registry entry was stuck at 0.4.83 since 2026-03-12 — 31 patch
releases behind npm, still flagged isLatest, and advertising a build predating
the v0.4.108 SSRF remediation.

Root cause: the release workflow bumped package.json and manifest.json but never
server.json, and npm publish does not touch the registry.

- server.json: 0.4.83 -> 0.4.114 (both version and packages[0].version)
- CLAUDE.md: server.json added to step 1, mcp-publisher publish as step 10 after
  npm publish, plus a curl one-liner to verify the published entry
- Published and verified: registry now serves 0.4.114 with isLatest true

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: aborruso

CLAUDE.md

@@ -459,7 +459,7 @@ npm cannot resolve relative paths from the tarball.
 
 When releasing a new version:
 
-1. **Update version**: Edit `package.json` version field and `manifest.json` version field
+1. **Update version**: Edit the version field in `package.json`, `manifest.json` **and `server.json`** (in `server.json` there are **two** fields: top-level `version` and `packages[0].version` — both must match)
 2. **Update LOG.md**: Add entry with date and changes
 3. **Commit changes**: `git add . && git commit -m "..."`
 4. **Push to GitHub**: `git push origin main`
@@ -468,10 +468,18 @@ When releasing a new version:
 7. **Build skill**: `npm run pack:skill` → produces `tmp/ckan-mcp.skill`
 8. **Attach to release**: `gh release upload v0.x.0 ckan-mcp-server.dxt tmp/ckan-mcp.skill`
 9. **Publish to npm** (optional): `npm publish`
-10. **Deploy to Cloudflare** (if code changed): `npm run deploy`
+10. **Publish to the MCP Registry** (after npm — the registry validates that the npm version exists): `mcp-publisher login github && mcp-publisher publish`
+11. **Deploy to Cloudflare** (if code changed): `npm run deploy`
 
 See `docs/DEPLOYMENT.md` for detailed Cloudflare deployment instructions.
 
+**Why steps 1 and 10 matter**: `server.json` feeds the official MCP Registry entry, which is what clients installing via the registry resolve. It is *not* updated by `npm publish`. Skipping it silently pins public installs to an old version: between v0.4.83 (2026-03-12) and v0.4.114 (2026-08-03) the registry advertised a build predating the v0.4.108 SSRF remediation, while npm was current. Verify after publishing:
+
+```bash
+curl -s "https://registry.modelcontextprotocol.io/v0/servers?search=io.github.aborruso/ckan-mcp-server" | \
+  jq -r '.servers[] | select(.server.name|test("aborruso")) | "\(.server.version) | pkg \(.server.packages[0].version) | latest \(._meta["io.modelcontextprotocol.registry/official"].isLatest)"'
+```
+
 ## CSV Data Exploration
 
 For exploring CSV resources from datasets, use duckdb CLI (already installed) with direct HTTP URL:

LOG.md

@@ -1,5 +1,18 @@
 # LOG
 
+## 2026-08-03
+
+### MCP Registry entry realigned to 0.4.114
+
+Published and verified against the public endpoint: the registry now serves **0.4.114** with `isLatest: true` (updated 2026-08-03T06:01:07Z), and the old 0.4.83 record dropped to `isLatest: false`.
+
+The official MCP Registry entry for `io.github.aborruso/ckan-mcp-server` had been stuck at **0.4.83 since 2026-03-12** — 31 patch releases and almost five months behind npm, while still flagged `isLatest: true`. Clients resolving the server through the registry were pointed at a build predating the v0.4.108 SSRF remediation, and 0.4.83 is still installable from npm.
+
+- Root cause, not a one-off slip: the Release Workflow in `CLAUDE.md` listed the version bump for `package.json` and `manifest.json` but never `server.json`, and `npm publish` does not touch the registry. The drift was structural and would have kept growing.
+- Fixed `server.json` (both `version` and `packages[0].version` — two fields, easy to half-update) and rewrote the release workflow: `server.json` added to step 1, a new step 10 for `mcp-publisher publish` placed after `npm publish` since the registry validates that the npm version exists, plus a `curl` one-liner to verify the published entry.
+- Surfaced by an unsolicited vendor email selling a £395 "MCP Readiness Audit". The sales pitch was worthless — the remedy it offered has nothing to do with the defect — but the three technical claims all checked out under verification. Worth recording: the finding was real and cost the sender two `curl` calls, which is exactly how long it would have taken us to catch it ourselves with a check in the release procedure.
+- Registry tokens (`.mcpregistry_*`) verified: gitignored, never committed.
+
 ## 2026-07-31
 
 ### v0.4.114

server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/ondata/ckan-mcp-server",
     "source": "github"
   },
-  "version": "0.4.83",
+  "version": "0.4.114",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@aborruso/ckan-mcp-server",
-      "version": "0.4.83",
+      "version": "0.4.114",
       "transport": {
         "type": "stdio"
       }