ci: fold release.yml into apple.yml and the two Windows client workflows into one

Two merges, both of which exist to express an ordering Gitea cannot express across
files, and both of which delete a duplicated build.

release.yml -> apple.yml (as the `distribute` job)
  The name described neither what it did (Apple only — every other platform's release
  is its own packaging workflow attaching to the same Gitea release on a v* tag, with
  announce.yml as the manual "go") nor anything a reader would guess. The name was the
  smaller problem. Gitea has no cross-workflow `needs`, so nothing sequenced it against
  apple.yml's tests: a canary main push uploaded iOS, macOS and tvOS builds to
  TestFlight even when `swift test` had just failed on that same commit. It is now
  `needs: swift`, which is only expressible in one file.

  The two files' paths: filters had also drifted — apple.yml watched crates/**,
  release.yml watched crates/punktfunk-core/**. The merged filter takes the NARROW one,
  because that is the correct one: everything on this runner is built from
  punktfunk-core via build-xcframework.sh, and punktfunk-core's only path dependency is
  its own vendored fec-rs. That is checkable in one command, and the header says so, and
  says to widen it if that ever stops being true. Net effect on the shared mac mini:
  pushes that touch host-side crates no longer build or upload anything Apple.

windows.yml + windows-msix.yml -> windows-client.yml
  The pair built the same three crates FOUR times per client push on ONE runner: debug
  x64 + arm64 for lint/test, release x64 + arm64 for packaging. windows-host.yml already
  records why a second (debug) dep tree on this machine is a liability rather than a
  cost — it re-runs openh264-sys2's vendored C++ through cc-rs's cl.exe fan-out and tips
  the runner into C1069, which is disk exhaustion wearing a compiler error's clothes. So
  there is one release build per arch now and clippy/fmt/test run against it, exactly as
  windows-host.yml does. The paths list went from three copies to one; PRs get the
  build/lint/test signal and stop before packaging.

The rename is safe, and this is worth recording because the GitHub instinct is wrong
here: `github.run_number` is REPO-WIDE in Gitea, not per-workflow — consecutive runs of
DIFFERENT workflows get consecutive numbers (verified against the API: android 13226,
apple 13227, arch 13228, ci 13229, deb 13230). The canary MSIX version <minor>.<run>.0
and Apple's CURRENT_PROJECT_VERSION therefore keep climbing across a rename. On GitHub
the same rename would reset both to 1, sorting every new canary below the published ones
and getting the TestFlight uploads rejected outright.

25 workflows, down from 27, and every `name:` now matches its filename. Cross-references
in windows-host.yml, windows-drivers.yml, android.yml, flatpak.yml, sbom.yml, the
provisioning scripts, gitea-release.sh and clients/windows/packaging/README.md updated.

scripts/ci/gitea-release.sh

@@ -2,7 +2,7 @@
 # Shared Gitea Release helpers for the punktfunk CI workflows (Linux + macOS runners).
 #
 # Source this file, then call ensure_release / upsert_asset. It replaces the three
-# copy-pasted inline blocks that used to live in release.yml / flatpak.yml / decky.yml,
+# copy-pasted inline blocks that used to live in apple.yml / flatpak.yml / decky.yml,
 # and fixes a latent bug those had: the bare asset POST returns 409 if an asset with the
 # same name already exists, so re-running a workflow — or reusing the rolling `canary`
 # release with stable filenames — would fail. upsert_asset deletes the old asset first.

scripts/ci/provision-windows-punktfunk-extras.ps1

@@ -1,6 +1,6 @@
 # Layers punktfunk-specific tooling onto the shared unom Windows CI runner: FFmpeg (the HOST's
 # amf-qsv encode leg, x64 only), Inno Setup (the host installer), and the aarch64-pc-windows-msvc
-# rustup target (windows-msix.yml's ARM64 leg). The runner itself - act_runner, Node, rustup,
+# rustup target (windows-client.yml's ARM64 leg). The runner itself - act_runner, Node, rustup,
 # VS Build Tools/NASM/CMake/LLVM - is provisioned generically by unom/infra
 # (windows-runner/windows-runner.pkr.hcl + proxmox/windows-runner's Terraform clone); this script
 # is what punktfunk adds on top, since FFmpeg/Inno Setup/the ARM64 target aren't every project's
@@ -15,7 +15,7 @@ function info($m) { Write-Host "[provision-punktfunk-extras] $m" }
 $env:RUSTUP_HOME = "C:\Users\Public\.rustup"
 $env:CARGO_HOME  = "C:\Users\Public\.cargo"
 
-# --- ARM64 cross-compile target (windows.yml / windows-msix.yml build aarch64-pc-windows-msvc off
+# --- ARM64 cross-compile target (windows-client.yml builds aarch64-pc-windows-msvc off
 # this x64 box; the ARM64 MSVC cross compiler itself comes from unom/infra's generic VS Build
 # Tools provisioning, which already includes the ARM64 component). ---
 $rustup = "C:\Users\Public\.cargo\bin\rustup.exe"
@@ -33,7 +33,7 @@ if (Test-Path $rustup) {
 # bundled DLLs LGPL-2.1+ (dynamic linking satisfies the relink duty) rather than GPL, so the
 # shipped installer/MSIX stay consistent with punktfunk's MIT OR Apache-2.0 posture.
 # ⚠ The CLIENT no longer links FFmpeg at all (M10, design/client-native-decode.md §6): it decodes
-# with pf-vkdecode / pf-dxvadec / openh264 + rav1d. windows.yml and windows-msix.yml set no
+# with pf-vkdecode / pf-dxvadec / openh264 + rav1d. windows-client.yml sets no
 # FFMPEG_DIR and the MSIX bundles no libav* DLLs, so only the x64 tree is fetched now - the ARM64
 # one existed solely for the ARM64 client leg. Delete a stale C:\Users\Public\ffmpeg-arm64 by
 # hand; this script does not remove what it no longer installs.

scripts/ci/provision-windows-wdk.ps1

@@ -8,7 +8,7 @@
 # installed. Safe to run repeatedly. Runs non-interactively (/q /norestart) — never auto-reboots.
 #
 # Invoked by scripts/ci/ensure-windows-toolchain.ps1, the shared self-provision step every Windows
-# CI workflow runs at job start (windows-drivers.yml, windows.yml, windows-msix.yml,
+# CI workflow runs at job start (windows-drivers.yml, windows-client.yml,
 # windows-host.yml), on top of the generic runner unom/infra provisions (windows-runner/) and
 # provision-windows-punktfunk-extras.ps1's FFmpeg/Inno Setup/ARM64-target layer. Run as the
 # runner's account (SYSTEM) with admin rights.

scripts/ci/setup-macos-runner.sh

@@ -94,7 +94,7 @@ fi
 # Deliberately NO DEVELOPER_DIR here: cargo (rust ld) must stay on the system default —
 # a newer-than-OS Xcode's ld emits dylibs the running dyld rejects ("mis-aligned
 # LINKEDIT string pool"), breaking every proc-macro build. Steps that need a full Xcode
-# (xcodebuild) resolve it themselves (build-xcframework.sh, release.yml).
+# (xcodebuild) resolve it themselves (build-xcframework.sh, apple.yml's `distribute` job).
 
 PLIST_STAGE="$RUNNER_HOME/io.gitea.act_runner.plist"
 PLIST_SYSTEM="/Library/LaunchDaemons/io.gitea.act_runner.plist"