docs(releasing): commit the version-stamp check and the auto-update warning

[ndemianc]

Rescues 38 lines that had been sitting uncommitted in the working tree across several releases, surviving only because nobody ran git checkout -- ..

They document two things the runbook needs, neither guessable from reading the scripts:

1. Verify the version stamp (§3)

The built app must report levelcodeVersion, not the Code-OSS base — and this fails silently, so it needs an explicit per-release check. Adds the one-liner, what each field must be, and a table mapping the two build log lines to good vs fix before publishing.

2. Publishing is deploying (§5)

With LEVELCODE_UPDATE_FEED_SIGNED=1, publishing a release makes every existing install download and apply it at its next check. No staged rollout, no percentage gate — and the rollback lever stops further propagation but cannot un-update anyone who already took it. Plus a curl to confirm the feed actually picked the release up (it caches for 5 minutes).

On authorship

I did not write this prose — it is pre-existing work by the repo owner. My contribution was verifying it before enshrining it, on the principle that committing an inaccurate runbook is worse than leaving it uncommitted:

• both quoted log lines exist verbatim — build-macos.sh:101 and :105
• stamp-levelcode-version.mjs does write levelcodeVersion, and deliberately leaves version at the Code-OSS base for engines.vscode, exactly as the note claims
• the feed path and the LevelCode Updater user-agent match what production nginx actually logs

Everything checked out, so it is committed as written.

Timely for v0.9.2: §5's warning is the reason the tag/sign/publish steps are worth doing deliberately rather than in one motion.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the release runbook to capture two critical release-time checks that aren’t obvious from reading the build/publish scripts: verifying the levelcodeVersion stamp and understanding that publishing a signed release triggers automatic rollout via the production update feed.

Changes:

• Clarifies build-macos.sh’s role (strip proprietary code + stamp release version) in the release command sequence.
• Adds an explicit per-release verification step to ensure product.json contains the correct levelcodeVersion (and explains how to interpret the two relevant build log lines).
• Adds a prominent warning that, with the signed update feed enabled, publishing a release deploys it to existing installs, plus a curl check to confirm the feed picked up the new release.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.