Replace build number formula with github.run_number

[FuJacob]

Summary

Replaces the custom build number derivation formula
(major*100000 + minor*1000 + patch) with github.run_number. The
formula was a bespoke scheme that could collide at component values >= 1000
and was one more thing contributors had to understand. github.run_number
is a built-in monotonic counter that just goes up — no math, no edge cases.

Sparkle only needs build numbers to increase between releases. It doesn't
care about gaps or specific values.

Validation

github.run_number is currently at ~27 for this workflow, which is higher
than the previous build number of 6 (from v0.0.6-beta). Sparkle will see
the next release as an upgrade.

Cannot test the actual github.run_number injection locally — it's a
GitHub Actions context variable. Verified the YAML is structurally correct
and the metadata step still emits build_number to GITHUB_OUTPUT.

Linked issues

Refs #185

Risk / rollout notes

• Build numbers will jump from 6 (v0.0.6-beta) to ~28+ on next release.
  This is fine — Sparkle only checks "is the new number higher?"
• workflow_dispatch dry runs consume run numbers. This is expected and
  harmless — numbers just need to go up, not be sequential.

Greptile Summary

Replaces the custom build number derivation formula (major*100000 + minor*1000 + patch) in the release workflow with GitHub's built-in github.run_number. The old formula was unnecessary complexity that could collide for component values ≥ 1000 and required a separate validation guard; github.run_number is always a positive integer so both the formula and the guard are cleanly removed.

• The build_number variable is now set directly to ${{ github.run_number }} inside the Resolve release metadata step; all subsequent steps (Archive signed app, Generate signed appcast, Release summary) consume it identically through steps.metadata.outputs.build_number — no other changes required.
• The removed validation (-z \"${build_number}\" || \"${build_number}\" -le 0) was genuinely unnecessary for github.run_number, which the GitHub Actions runtime guarantees is always a positive integer starting from 1.

Confidence Score: 5/5

This is a safe, surgical change that removes nine lines of formula-and-validation logic and replaces them with a single well-understood GitHub Actions built-in.

The change is minimal and correct. github.run_number is monotonically increasing and always a positive integer, so removing the old validation guard leaves no gap in correctness. All downstream consumers of build_number remain unmodified and continue to work through the same steps.metadata.outputs reference. The jump in build number value from ~6 to ~28 is intentional and harmless for Sparkle's update detection.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Replaces bespoke major100000 + minor1000 + patch formula and its validation guard with a single github.run_number assignment; all downstream consumers (CURRENT_PROJECT_VERSION, appcast generation, step summary) continue to receive build_number from the same steps.metadata.outputs reference unchanged.

_{Reviews (1): Last reviewed commit: "Replace build number formula with github..." | Re-trigger Greptile}