Three insiders, then one stable

Master stays at the last stable version while insiders preview the next target. Stable promotes the final tested source SHA.

master invariant package.json stays at the last shipped stable until the post-release PR merges.
version source CHANGELOG.md ## Unreleased headings compute the next stable version. 
sequenceDiagram
    participant PR as PRs
    participant M as master
    participant I as Insiders feed
    participant S as Stable release
    participant R as Post-release PR

    Note over M,I: repo still says 0.63.4
Unreleased computes 0.64.0
    PR->>M: merge feature/fix
    M->>I: cut v0.64.0-insiders.0 (tag B)
    Note right of I: testers get build .0
    PR->>M: merge candidate
    M->>I: cut v0.64.0-insiders.1 (tag C)
    Note right of I: testers get build .1
    PR->>M: merge final fix
    M->>I: cut v0.64.0-insiders.2 (tag D)
    Note right of I: testers approve build .2
    I->>S: promote source SHA D
    S->>S: tag v0.64.0 on D
rebuild public artifacts
    S->>R: generate PR from D
    R->>M: merge version + changelog bump
    Note over M: package.json = 0.64.0
CHANGELOG has ## v0.64.0
newer bullets remain Unreleased

What actually changes in files

The workflows build from computed versions in CI. The repository only catches up after the generated post-release PR merges.

Before stable

package.json: 0.63.4 CHANGELOG: ## Unreleased Insider artifacts have 0.64.0-insiders.N, but that version is not committed.
->

Post-release PR

package.json: 0.64.0 CHANGELOG: ## v0.64.0 Generated from released SHA D, moving shipped bullets out of Unreleased.
->

After merge

package.json: 0.64.0 CHANGELOG: ## v0.64.0 Master now matches stable. Later work continues under Unreleased.
Key point: v0.64.0-insiders.2 and v0.64.0 point at the same source SHA; stable rebuilds public artifacts instead of republishing the insider binary.