feat(canary): host updater manifest on Pages, redesign tag schema

[dryotta]

Problem

Earlier today we hit HTTP 422: Cannot upload assets to an immutable release on the canary build after enabling Enable release immutability. PR #394 made the upload pattern immutability-safe (draft -> upload -> undraft), but the deeper issue surfaced on the next push: GH013: Cannot create ref due to creations being restricted when force-pushing the mutable canary tag. Empirical testing confirmed:

• Release Immutability permanently reserves the tag-name of any release it ever protects.
• Reservations survive release deletion and disabling the setting (verified with probe-tag tests).
• The legacy mutable-canary-tag design is structurally incompatible with the feature no workflow tweak can resurrect it.

Redesign (this PR)

Three principles that hold under any immutability setting:

1. Unique-per-build canary tag schema

\
canary-{YYYYMMDDHHMMSS}-{run}-{shortsha}
\\

Example: canary-20260516181801-198-3be43cf

• Globally unique (timestamp + SHA make collisions impossible).
• Lex-sortable gh release list gives chronological order.
• Traceable clicking the tag in GH UI lands on the exact commit.
• Immutability-friendly every tag is created exactly once and never moved.
• Run-number-resilient survives GITHUB_RUN_NUMBER reset (e.g. workflow YAML recreation).

2. "Latest canary" pointer hosted on GitHub Pages

Manifest moves from a mutable release asset to a tracked file at site/canary-latest.json, deployed by the existing pages.yml workflow. URL:

\
https://dryotta.github.io/mdownreview/canary-latest.json
\\

Decoupled from the release subsystem entirely immune to immutability reservations now and in the future.

3. Codified recovery contract

If the Pages manifest is ever unreachable, canary users recover with three clicks:

1. About dialog -> Update channel: Canary -> Stable
2. Check for Updates -> install latest stable (which always has a working CANARY_ENDPOINT baked in)
3. Update channel: Stable -> Canary

This is now documented in docs/features/updates.md as the system's intentional recovery mechanism. No maintainer intervention required.

Mechanics

The publish-canary-manifest job now:

1. Generates site/canary-latest.json with the new release's URLs + signatures.
2. Commits + pushes to main (3-attempt rebase fallback for races with concurrent human commits).
3. Explicitly dispatches pages.yml via gh workflow run because GITHUB_TOKEN-driven pushes do not auto-trigger other workflows.

Permissions added: actions: write (for the dispatch).

The Clean up old canary releases step is filtered strictly to the new tag schema (regex) so legacy canary-{N} releases are left in place clean those up manually after the v0.4.7 cycle. Retention bumped 5 -> 10.

Stable channel

Completely untouched. release.yml, latest.json publication, v*.*.* tag schema, releases/latest/download/latest.json endpoint all unchanged. Verified end-to-end via the v0.4.6 manifest fetch + the no-op release.yml diff.

Backward compat

Cohort	Outcome
Stable users (v0.4.6 and earlier)	Zero impact. Next stable release ships normally.
Canary users on 0.4.6-191 ... 0.4.6-197	Stranded on dead URL until they flip to Stable, update, flip back. The recovery contract is documented and tested via the existing cross_channel override in update.rs:58.
New canary users (any build from this PR forward)	Auto-update works via the Pages URL.

Verification path

• cargo check --quiet -> compiles
• Both workflow YAMLs parse via yaml.safe_load ->
• Only 3 files reference the canary URL pattern, all updated ->
• End-to-end CI on this PR -> covers Rust build, type-check, lint, unit tests, native E2E, all 3 platform builds, bindings drift
• Real-world validation: requires merge to main + at least one new push to trigger canary; first such canary run will exercise every new code path (new tag schema, manifest commit, pages.yml dispatch, Pages deploy)

Out of scope (separate cleanup)

• ~17 orphaned canary-build/canary-19x branches accumulated during today's failing canary runs. Can be cleaned up manually post-merge.
• Legacy canary-19x releases (191, 192, 193, 195, 196, 197) -- left in place; the new cleanup filter ignores them by design. Manual deletion at your discretion.