[SWR-VERSION-BUILD-STAMPING] 0.0.0-dev placeholder is hazardous for VS Code extension package.json

Context

reference/audit-checklist.md §3.1 and binary-version-contract.md (SWR-VERSION-BUILD-STAMPING) mandate that all source version carriers — including a VS Code extension's package.json version — be set to the placeholder 0.0.0-dev, with the real version stamped from the git tag in the runner working tree before build/package.

For a standalone Rust/CLI binary this is fine. For a published VS Code extension it is risky, and I'd like to flag it.

The problem

package.json version is not just a build input for an extension — it is:

1. The Marketplace version of record. vsce package/vsce publish read it directly. If stamping fails, is skipped, or a non-tag build path runs vsce package, a 0.0.0-dev VSIX can be produced or published. There is no second source of truth to catch the regression.
2. Read by tooling and humans constantly outside the release path — local F5 debug builds, npm run package for manual install, dependabot/renovate, the extension host's own context.extension.packageJSON.version. All of these now see 0.0.0-dev instead of the true semver.
3. A semver-invalid Marketplace state if it ever leaks. The Marketplace rejects/garbles 0.0.0-dev, and a bad publish to an already-published extension (e.g. Nimblesite.sem at 0.3.0) is hard to roll back.

The spec's "stamp before package, never commit the bump" rule does technically work, but it makes the correct version depend entirely on the stamping step never being bypassed — a fragile invariant for the one file that is also the live distribution manifest.

Suggested resolution

Carve out an explicit exception (or guidance) for VS Code extension package.json:

• Option A: Allow the extension package.json to retain its real released version in source, and stamp/verify it equals the tag at release time instead of forcing 0.0.0-dev.
• Option B: If 0.0.0-dev is retained, require a hard CI gate that fails any vsce package/publish whose effective version is 0.0.0-dev, plus a non-tag-build guard, and document the context.extension.packageJSON.version implications.

Either way the spec should acknowledge that for IDE-extension manifests the version field is a live distribution artifact, not a pure build input, and treat it differently from a Rust Cargo.toml.

Repro context

Found while running the shipwright-compliance skill against a VS Code extension (Nimblesite.sem, published at 0.3.0). The audit flagged §3.1 as FAIL for not using 0.0.0-dev; applying the fix as written would set the live Marketplace manifest to a semver-invalid placeholder.

Read reference/audit-checklist.md §3.1 and binary-version-contract.md, then trace the release path that stamps versions before vsce package or publish. Compare the two proposed treatments for a VS Code extension package.json and document the selected rule, including safeguards for non-tag builds and effective 0.0.0-dev versions.