ci: cache hygiene + faster builds

[ntatschner]

Summary

Workflow-only CI speed-up. No app code, no change to release binaries or local dev.

• rust-cache save-if — every Swatinem/rust-cache@v2 block now sets save-if: ${{ github.ref == 'refs/heads/next' || github.ref == 'refs/heads/main' }} (across ci.yml, release.yml, promote.yml). PR runs restore from the shared cache but stop writing to it, so PRs no longer pollute the branch-scoped cache with throwaway state; only next/main pushes refresh it.
• No-incremental dev builds — added a top-level env: (CARGO_INCREMENTAL: "0", CARGO_PROFILE_DEV_DEBUG: "0") to ci.yml, release.yml, promote.yml. This is the documented rust-cache best practice: incremental compilation bloats the cache for no benefit on a clean-checkout runner, and dropping dev/test debuginfo shrinks target/ further. Release builds use the release Cargo profile and are unaffected.
• mold linker on Linux — added rui314/setup-mold@v1 (guarded if: runner.os == 'Linux') right after dtolnay/rust-toolchain in every job that compiles Rust, across all three workflows. Linking is a large share of the Tauri build time; mold cuts it substantially. No-ops cleanly on the Windows matrix legs.
• Docker build cache: gha → registry — release-images.yml's three cache pairs (API, Web, matrix config-images) now push/pull type=registry cache to ${{ secrets.REGISTRY_URL }}/starstats/<image>:buildcache instead of type=gha. The GH Actions cache backend has a 10 GB repo-wide cap and branch-scoped eviction that was thrashing; the private registry (already authenticated via the existing login step) has no such limit and persists across branches.

Test plan

• python -c "import yaml; ..." — all 4 workflow files parse cleanly.
• actionlint not installed locally — CI's own actionlint job (gated on workflow-file changes) will lint this PR.
• Grep-verified: every Swatinem/rust-cache@v2 block has a matching save-if:; every type=gha in release-images.yml is gone; each of the 3 Rust-touching workflows has CARGO_INCREMENTAL + matching mold steps (counts line up 1:1 per file).
• First real run on this PR (restore-only rust-cache path) and first push to next after merge (cache-write + mold + registry-cache paths) are the two things to actually watch — see Concerns below.

Concerns / things to watch on first run

• mold is new to this repo's CI; if a linker incompatibility shows up on the Linux runner image, the fix is to drop the step for the affected job (it's additive and isolated per-job).
• registry-cache assumes the registry accepts arbitrary :buildcache tags at starstats/<image>:buildcache and that mode=max cache layers don't blow past registry quota. First release-images.yml run after merge (or the next branch/tag push that fires it) is the real test — worth checking the Build & push steps' timing/log output specifically.
• No release binaries, migrations, or app code touched by this PR.

Roadmap: untracked (CI-only chore, no user-visible behaviour change).