ci: stop bumping patch for nightly builds (fixes macOS sysext downgrade trap)

[myleshorton]

Summary

• scripts/ci/version.sh generate nightly no longer increments the patch. Nightlies now reuse the most recent tagged base version (9.1.9-<sha>-<timestamp> instead of 9.1.10-<sha>-<timestamp>).
• Beta version generation is unchanged — it still bumps patch.
• Uniqueness for nightlies continues to come from the SHA + timestamp in the tag suffix and from CFBundleVersion (github.run_number), which is monotonic across all workflow runs.

Why

macOS pins system-extension upgrade/downgrade decisions on CFBundleShortVersionString. With the old behavior, a nightly built ~7 hours after v9.1.9-beta advertised CFBundleShortVersionString = 9.1.10. Users who installed that nightly and then reverted to the v9.1.9-beta DMG triggered the OS downgrade path, which returned OSSystemExtensionErrorDomain code 4 (extensionNotFound) on activation and bricked the network extension — reproduced as bug #5 in getlantern/engineering#3474 (Ryan).

Keeping the nightly base equal to the latest beta makes the beta ↔ nightly transition a same-version content change. The reconciler updates in #8745 and #8751 already handle that path correctly via .deactivateThenActivate.

sequenceDiagram
    autonumber
    participant CI as Nightly CI<br/>scripts/ci/version.sh
    participant Pubspec as pubspec.yaml<br/>release.yml:226
    participant macOS as macOS SystemExtensions<br/>(activation registry)
    participant User as Ryan's Mac

    Note over CI,Pubspec: BEFORE this PR
    rect rgba(255, 200, 200, 0.3)
        CI->>Pubspec: generate nightly → 9.1.10-sha-ts ⚠️<br/>(patch bumped past v9.1.9-beta)
        Pubspec->>User: 9.1.10 DMG installed
        User->>macOS: activate org.getlantern.lantern.PacketTunnel<br/>CFBundleShortVersionString=9.1.10
        Note over macOS: extension registered ✅
        User->>User: revert to v9.1.9-beta DMG
        User->>macOS: activate (CFBundleShortVersionString=9.1.9)
        Note over macOS: downgrade detected →<br/>OSSystemExtensionErrorDomain code 4 🐛
    end

    Note over CI,Pubspec: AFTER this PR
    CI->>Pubspec: generate nightly → 9.1.9-sha-ts<br/>(same base as latest tag)
    Pubspec->>User: nightly DMG (CFBundleShortVersionString=9.1.9)
    User->>macOS: activate (same base)
    Note over macOS: classifyChange → .contentChange<br/>→ deactivateThenActivate ✅

Loading

Test plan

• scripts/ci/version.sh generate nightly returns 9.1.9-<sha>-<timestamp> against current tags (verified locally — 9.1.9-41ae88c-20260514T170704Z)
• scripts/ci/version.sh generate beta still returns 9.1.10-beta (unchanged)
• scripts/ci/version.sh extract 9.1.9-<sha>-<timestamp> returns 9.1.9
• scripts/ci/version.sh validate 9.1.9-<sha>-<timestamp> passes (the base 9.1.9 is not less than the highest existing version 9.1.9)
• Next scheduled nightly tags as v9.1.9-<sha>-<timestamp> and the resulting pubspec is 9.1.9+<run_number>
• Manual repro of the downgrade: install nightly, then install v9.1.9-beta, confirm system extension activates without error 4

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adjusts the CI version generator so nightly builds reuse the most recent tagged base version instead of bumping the patch. This avoids advertising a higher CFBundleShortVersionString than the latest beta, which on macOS triggers a system-extension downgrade error (OSSystemExtensionErrorDomain code 4) when users revert from a nightly to a beta. Beta generation behavior is unchanged.

Changes:

• Drop the increment_patch step in the generate nightly branch; emit ${BASELINE}-${SHA}-${TIMESTAMP} directly.
• Update header examples and add an inline rationale comment explaining the macOS sysext motivation.

---

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

[myleshorton]

Closing in favor of option 1 from the discussion thread — fixing this in the reconciler (stale-registry recovery on extensionNotFound) rather than papering over the version-bump path. The CI patch only helps the nightly→beta loop; option 1 generalizes to any downgrade scenario.