feat(cli): stamp git commit into version

[atoomic]

What

Adds a build-time codegen step that stamps the short git commit into a root-level build-info.json, read at runtime to decorate the version string — e.g. haze --version shows 0.6.0@e5c03c0 instead of a bare 0.6.0.

Why

Dev/local installs (symlinked global install, tsx, node dist) were previously indistinguishable from published releases — both showed plain 0.6.0 — so there was no way to tell what was actually running. This makes the built-from commit visible at a glance.

How

• New scripts/build-info.mjs captures git rev-parse --short HEAD (degrades to null if git is unavailable) and writes build-info.json at the repo root.
• npm run build-info runs the step; it's chained into dev, build, and haze. Stamping happens at build time, so the version reflects the commit dist was built from (rebuild after switching branches for it to update).
• At runtime, src/cli/index.ts reads the stamp and decorates the version for --version, the chat header, and session metadata. A missing or malformed stamp degrades to the plain version with no error.
• The stamp file sits at the repo root, which is outside the npm files allowlist, so npm excludes it from the published tarball and releases still show plain 0.6.0.
• The update check keeps the clean base version via a new baseVersion prop, since the @-decorated form is not valid semver and would mis-parse in isNewer (e.g. 0.6.0@e5c03c0 would parse as release 0.6.5030).
• build-info.json is gitignored (a build artifact, not source).
• New formatVersion(base, commit) helper is pure and unit-tested.

Verification

• npm run typecheck — clean
• npm test — 796 passed / 86 files
• npm run lint (eslint src/) — clean
• Functional: dev path shows 0.6.0@e2e1aa1; with the stamp absent (published-tarball simulation) it shows 0.6.0.

🤖 Generated with Claude Code