refactor(ci): unify build + release workflows into a single release.yml pipeline

## Summary
The new dev-release workflow in #1217 works, but the release/build architecture is now split across:
- `.github/workflows/dev-release.yml`
- `.github/workflows/build.yml`
- `.github/workflows/build-tauri.yml`

This is functional, but harder to reason about than the unified `release.yml` design we ended up with in `gptme/gptme`.

## Why this follow-up exists
In ActivityWatch/activitywatch#1217, Erik asked why we didn't use the cleaner unified `release.yml` structure from `gptme/gptme`.

The answer is basically scope control: #1217 started as the smallest safe change that could add CI-gated dev prereleases on top of ActivityWatch's current workflow layout. That was the right call for landing the feature quickly, but the architectural cleanup still makes sense.

## Proposed direction
Refactor the current release/build setup into a single `release.yml`-style workflow that:
- handles both stable and prerelease tagging paths coherently
- owns release creation logic in one place
- dispatches/reuses build steps instead of duplicating release semantics across multiple workflows
- keeps artifact naming/version derivation consistent across AW Qt / Tauri outputs
- makes the CI gate for dev releases easier to understand and audit

## Constraints
- Keep the safety properties added in #1217:
- exact-SHA tagging after CI verification
- robust self-exclusion for current workflow run
- explicit handling of cancelled/startup_failure conclusions
- Don't regress stable release behavior
- Preserve draft prerelease behavior unless we intentionally change it

## Context
- PR: ActivityWatch/activitywatch#1217
- Reference design: `gptme/gptme/.github/workflows/release.yml`

## Outcome
This would reduce workflow sprawl and make future release automation changes less brittle.