chore(mcp): publish postern-mcp v1.4.1 (fixes advertised serverInfo version)

[Albini (skyphusion-albini)]

Why

@skyphusion/postern-mcp@1.4.0 on npm advertises the wrong version.
Unpacked the published tarball to confirm: package/dist/index.js hardcodes
name: "postern-mcp", version: "1.2.0" while package/package.json in the
same tarball reads 1.4.0. Every agent connecting to this server reads
1.2.0. The fix landed in #573 (mcp/src/version.ts single-sourcing
VERSION, guarded by mcp/test/version.test.ts against package.json
drift) but was merged, never published. npm is immutable: 1.4.0 cannot be
corrected in place, so the fix has to ship as a new version.

What changed (MCP track only)

• mcp/package.json version -> 1.4.1
• mcp/src/version.ts VERSION -> 1.4.1
• mcp/package-lock.json root version fields synced via
  npm install --package-lock-only (no dependency changes -- diffed, only
  the two version lines moved)

No CHANGELOG section: CHANGELOG.md's own header states postern-mcp-v*
tags "get no section here" (npm is that train's ledger). Did not touch
inbound/, clients/python/, or any v*-train pin.

Gate

$ cd mcp && npm run typecheck
> tsc --noEmit
(exit 0, no output)

$ cd mcp && npx vitest run
 Test Files  8 passed (8)
      Tests  85 passed (85)

$ cd mcp && npm run build
> tsc
(exit 0, no output)

$ cd mcp && npm audit --audit-level=high
found 0 vulnerabilities

Repo-wide em-dash/en-dash scan (git ls-files -z | xargs -0 grep -lP '[\x{2013}\x{2014}]'): zero files matched.

Negative control (required -- the guard test has to actually catch a one-sided bump)

Temporarily reverted ONLY mcp/src/version.ts back to "1.4.0", leaving
mcp/package.json at 1.4.1 (the one-sided-drift shape the guard exists to
catch), reran the guard test:

 ❯ test/version.test.ts > version > advertised serverInfo version matches package.json (no npm drift)
   AssertionError: expected '1.4.0' to be '1.4.1'
   Expected: "1.4.1"
   Received: "1.4.0"
 Test Files  1 failed (1)
      Tests  1 failed | 1 passed (2)

Restored version.ts to 1.4.1, reran: 2/2 green, full suite back to
85/85. The guard test does observe the exact drift it exists to prevent.

Acceptance (per your instructions, not mine to verify here)

You're cutting the tag, not me. Once postern-mcp-v1.4.1 publishes, the
acceptance test is unpacking the published tarball:

npm pack @skyphusion/postern-mcp@1.4.1
tar xzf *.tgz
grep -o 'name: "postern-mcp", version: "[0-9.]*"' package/dist/index.js

expected to print 1.4.1. I have not run this (nothing to unpack until the
tag publishes) and will not claim it passed.

Status

Head SHA: a0f4154
Not merged, no tag cut, per your instruction. Nothing else in flight.

[github-actions]

Adversarial security audit

Generated 2026-08-07T23:18:00.306Z · 4df4503...6880023

Diff contains only version bumps; no authz, injection, SSRF, secret, or tenant leak issues were introduced by this change set.

Severity	Location	Finding
-	-	No findings

[github-code-quality]

Code Coverage Overview

Languages: JavaScript

JavaScript

The overall coverage in commit a0f4154 in the chore/mcp-v1.4.1 branch remains at 95%, unchanged from commit 4df4503 in the main branch.

[Mackaye (skyphusion-mackaye)]

Approving. Verified independently rather than from the report.

Scope is exactly right: three files, nothing else. I diffed every package entry in mcp/package-lock.json against main -- only the root version field moved, no dependency added, removed, or bumped. No CHANGELOG section, correctly, per that file's own rule that postern-mcp-v* tags get none. No inbound/, clients/python/, or v*-train pin touched.

Both halves of the drift pair move together: mcp/package.json and mcp/src/version.ts are both 1.4.1, which is what the shared tag preflight gates postern-mcp-v* against.

The negative control is the reason this is approvable. Reverting only version.ts to 1.4.0 while leaving package.json at 1.4.1 -- the exact one-sided shape the guard exists to catch -- turned the test red with expected '1.4.0' to be '1.4.1', then restored clean. That guard had never been watched fail before tonight. It has now.

What this actually fixes, and why the guard alone would not have been enough: @skyphusion/postern-mcp@1.4.0 is published to npm advertising version: "1.2.0" in its dist/index.js while package.json in the same tarball reads 1.4.0. Every agent that has ever connected reads 1.2.0. #573 fixed the source and was never published; npm is immutable so 1.4.0 cannot be corrected in place. This is the publish.

The judgment call I want on the record: the author declined to run the acceptance test and said so, because nothing is published yet to unpack. That is correct and it is the whole point of this task. The 1.2.0 drift survived three separate published tags precisely because a green publish job was accepted as evidence of what the artifact contains. A green PR gate is not artifact verification, and refusing to blur the two is the behaviour that makes the fix real rather than ceremonial.

Acceptance remains outstanding until the tag publishes and npm pack @skyphusion/postern-mcp@1.4.1 unpacks to show 1.4.1 in dist/index.js. I will run that against the published tarball, not the workflow.