Adopt the shared build-identity contract: st --version has no build identity, MCP serverInfo reports a different version

[schickling-assistant]

st --version carries no build identity, and the MCP server advertises a different version entirely.

Today

src/cli.ts reads the manifest at runtime:

function versionString(env: NodeJS.ProcessEnv): string {
  const here = fileURLToPath(import.meta.url);
  const pkgPath = join(dirname(here), '..', 'package.json');
  const pkg = JSON.parse(readFileSync(pkgPath, 'utf8')) as { version: string };
  return `${invokedName(env)} ${pkg.version}\n`;
}

So st --version → st 0.3.0. No revision, no dirty flag, no indication of whether this is a checkout or a packaged build.

Separately, src/mcp/capabilities.ts hardcodes a second, hand-maintained version:

export const SERVER_INFO: Implementation = {
  name: 'coord',
  // Tracks the package version. We don't read package.json here to keep
  // the MCP module side-effect free; bump on every coord release.
  version: '0.9.1',
};

It has drifted. An MCP host sees coord 0.9.1 while the CLI reports st 0.3.0 and the packaged artifact is named 0.3.0. serverInfo is the only machine-visible identity surface this project has, and it is the one that is wrong.

There is no telemetry, so no service.version.

Proposed: adopt the shared build-identity contract

Model the same canonical fields we use in our other CLIs, and derive two outputs from them:

field	meaning
baseVersion	package version from the manifest
rev	short VCS revision of the built source
dirty	uncommitted changes present at build/run time
sourceKind	local (running from a checkout) or nix (packaged build)
commitTs	commit timestamp

• machineVersion — stable and parseable, for telemetry, APIs, logs, and exact comparison: 0.3.0, 0.3.0+7d5211e, 0.3.0+7d5211e-dirty. No prose, no relative time.
• displayVersion — human-facing, for --version: 0.3.0+7d5211e — committed 4 days ago.

Canonical names, so this stays consistent with our other tools:

• source placeholder: __CLI_BUILD_STAMP__
• runtime env var for source runs: CLI_BUILD_STAMP

Scope

• One version source for the whole project. --version prints displayVersion; MCP serverInfo.version gets machineVersion — never a separate literal that must be bumped by hand.
• Add the __CLI_BUILD_STAMP__ placeholder and the resolver here. This repo is consumed as a plain source (not as a flake), so the packaging that substitutes the stamp lives in the consuming build; this side needs the placeholder, the CLI_BUILD_STAMP fallback, and the formatter.
• Keeping the MCP module side-effect free is still fine — the stamp is a compile-time constant, not a filesystem read, so the reason the literal exists goes away.

The name: 'coord' half of serverInfo belongs to #11 (rename to smalltalk), not here; this issue is only about the version value.

Sibling issues adopting the same contract: compoundingtech/pty#107, compoundingtech/convoy#83. The three should land the same field names and the same two derived outputs so a version string means the same thing across the toolchain.