fix: keep autocomplete artifact version stamp correct at tag time

[gtchax]

Fixes #24.

Problem

artifacts/autocomplete-types.ts is committed so consumers can fetch it at a tagged ref, but it was only ever corrected by a follow-up push to main. The v0.8.0 tag was cut at the bump commit (ada2251), and the regeneration commit (ea13b0d) landed after it:

ea13b0d  🤖 Auto-generate autocomplete types [skip ci]   <-- main only, stamped 0.8.0
ada2251  Bump version to 0.8.0                           <-- v0.8.0 tag, stamped 0.7.0

Tags are immutable, so that fixup can never reach v0.8.0 — it ships the 0.8.0 method set labelled SDK_VERSION = "0.7.0". This is what blocked pinning the runtime fetch to a tag in automators-com/loop#2825.

It's a race rather than a systematic off-by-one: v0.7.0 happens to be self-consistent. It breaks whenever the bump and the regeneration land in separate commits with the tag cut between them, which means a future release could come out clean by luck and mask the bug.

Fix

Make the stamp correct at tag time instead of repairing it afterwards.

• --check in the generator — regenerates in memory, diffs against the committed file, exits 1 with the diff if stale. One source of truth for both guards below.
• PR verify job (generate-autocomplete.yml) — a bump that forgets to regenerate now fails review, forcing the artifact into the same commit the tag will point at.
• Release guard (python-publish.yml) — verifies before building. It runs in release-build, which pypi-publish needs, so a mislabeled artifact can never reach PyPI.
• Dropped the release: published trigger from the generate job — it regenerated from a detached tag checkout and pushed to the branch, so it could never move the tag it was meant to fix.

Also fixed get_version() to resolve pyproject.toml against the repo root rather than CWD; it would silently stamp unknown when run from elsewhere, and --check now hard-fails on that instead.

0.8.1

Bumped to publish a correctly stamped tag, since v0.8.0 can't be corrected in place. The method set is unchanged from 0.8.0 — 89 methods both sides; the entire artifact diff is the two stamp lines:

-// Generated from version 0.8.0      +// Generated from version 0.8.1
-export const SDK_VERSION = "0.8.0";  +export const SDK_VERSION = "0.8.1";

Verification

• --check exits 1 on a simulated stale artifact (bumped pyproject, un-regenerated file) and prints the offending diff; exits 0 on a clean tree.
• Generator is byte-for-byte reproducible against the committed artifact, so the guard won't produce false failures.
• 68 unit tests pass.

Leaves open whether to retag/yank 0.8.0 — it's a published release, so that's a judgement call rather than something to fold into this PR.

🤖 Generated with Claude Code

[gtchax]

Follow-up once this merges: tag v0.8.1 at the merge commit — bare tag only, no GitHub release.

Deliberately not cutting a release: the release: published event triggers python-publish.yml → PyPI, and 0.8.1 carries zero functional change from 0.8.0 (89 methods, byte-identical apart from the two version-stamp lines). A PyPI publish would be a no-op release, and it's irreversible — PyPI won't allow re-uploading a version. A bare tag is all automators-com/loop#2825 needs, since it fetches artifacts/autocomplete-types.ts at a tagged ref.

Worth a reviewer's eye on two judgement calls in here:

1. Dropping the release: published trigger from the generate job. It regenerated from a detached tag checkout and pushed to the branch — it could never move the tag it was meant to fix, so it was a no-op at best. Shout if it was load-bearing for something I've missed.
2. v0.8.0 is left as-is — still published, still mislabeled. Retagging or yanking a released version felt like a call to make deliberately rather than fold into this PR. Fixing forward via 0.8.1 sidesteps it, but 0.8.0 stays a trap for anyone who pins to it.