fix(updater): isolate research update trust and normalize versions

[TimeToBuildBob]

Research Tauri builds currently embed the standard updater endpoint/key, and the updater manifest emits 0.14.0b5 while the app embeds 0.1.0. Configure update trust before compilation and use one version conversion for both app and manifest (0.14.0-beta.5), retaining original tag/asset URLs.

• Research builds use the independent research-updates/latest-research.json endpoint and a distinct public key. Secret selection uses edition-specific names, so missing research secrets cannot fall back to standard signing.
• Research tag/manual builds fail without their public/signing keys. Secretless research PR smoke builds clear update trust. Standard trust is preserved.
• Add CLI/workflow tests to the existing Research Edition smoke job and document signing setup and release acceptance in scripts/package/UPDATER.md.

Validation: 67 tests passed, 6 unrelated Qt/source-fixture tests skipped locally; actionlint and Ruff clean; real pinned Tauri profile patch targets verified; semver 1.0.27 rejects the old beta spelling and accepts normalized versions with correct equal/newer ordering. Full platform builds and installed-app upgrades have not been run locally.

This is build configuration, not completed release acceptance. Before publishing: provision TAURI_UPDATER_PUBLIC_KEY_RESEARCH, TAURI_SIGNING_PRIVATE_KEY_RESEARCH, and TAURI_SIGNING_PRIVATE_KEY_PASSWORD_RESEARCH; provision/publish the independent feed with monotonic expected-parent updates; verify actual signatures, built versions, upgrades, and payload/profile preservation. Existing standard-key research installs require replacement or verified containment before a valid standard stable manifest is published. Fixtures do not verify private/public key pairing or cryptography. The versioned draft manifest asset does not publish the live branch feed.

Follows the profile-isolation work in #1434 and #1437; this PR does not change that patch table or close the broader updater acceptance work.

[greptile-apps]

Confidence Score: 4/5

The PR should not merge until beta-derived development versions are encoded below their corresponding tagged releases so updater comparisons remain monotonic.

Findings

1.  Development Versions Sort Newer ▶

Summary

• Configures the Tauri version and research endpoint/public key before compilation.
• Selects signing secrets by edition and fails closed for publishable research builds missing their keys.
• Clears inherited updater trust from secretless research smoke builds.
• Adds workflow and CLI tests plus release-acceptance documentation.
• The development-version conversion currently orders beta-derived development builds above the corresponding beta release, preventing those builds from accepting that release as an update.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Git tag or development commit] --> B[getversion.sh]
    B --> C[tauri_version conversion]
    C --> D[Compiled Tauri app version]
    C --> E[Tagged-release updater manifest]
    F{Research build?} -->|No| G[Standard endpoint and key]
    F -->|Yes, keys present| H[Research endpoint and key]
    F -->|Yes, smoke build without keys| I[Updater trust cleared]
    D --> J[Tauri updater comparison]
    E --> J
    K[beta.5.dev.gHASH currently sorts above beta.5] --> J

Loading

[greptile-apps]

Development Versions Sort Newer

For a non-tag build based on 0.14.0b5, this appends the development identifiers and embeds 0.14.0-beta.5.dev.g<hash>. SemVer considers that version newer than 0.14.0-beta.5, so a standard development build that retains updater trust will reject the eventual beta release as an older version instead of accepting the update.

Knowledge Base Used:

• Build and distribution
• Automation and maintenance
• Packaging assets

[TimeToBuildBob]

Acknowledged — dev-suffix versions (e.g. 0.14.0-beta.5.dev.g<hash>) do sort newer than 0.14.0-beta.5 under SemVer, which would cause a developer build that retained updater trust to reject the eventual beta release as "older".

The PR already mitigates the practical risk in two ways: smoke/PR builds clear update trust (secretless research PR smoke builds clear update trust), so CI artifacts aren't affected. Tagged release builds are the intended distribution path for research keys; non-tag developer builds with research keys are an advanced/manual scenario the PR description already flags as out-of-scope for this build-config PR (Full platform builds and installed-app upgrades have not been run locally).

A follow-up to strip the dev suffix (or force-disable updater trust for non-tag builds) would be the clean fix, but it belongs in a follow-up once the trust isolation itself is validated.

[TimeToBuildBob]

CI was failing on Build Tauri artifacts (windows-latest, ...):

failed to bundle project: `optional pre-release identifier in app version must be numeric-only and cannot be greater than 65535 for msi target`

Root cause: tauri_version() maps AW's beta/rc/dev suffixes to SemVer pre-release strings like 0.14.0-beta.5 or 0.14.0-dev.gabc1234, but Tauri's msi (WiX) bundler rejects any non-numeric pre-release identifier. Since bundle.targets: "all" on Windows builds both msi and nsis, this broke every non-final-release Windows build — not just this PR's smoke build, but real beta/rc tags too.

Fixed in 535d3e4: configure_tauri_release.py now drops msi from bundle.targets on Windows when the computed version is msi-incompatible, keeping nsis (which has no such restriction). Added unit tests (test_msi_rejects, plus platform-gated configure() tests) alongside the existing subprocess-driven tests — 45/45 passing locally.