ci: take the release pipeline's action majors together

[lorem-dev]

Supersedes #55 and #56. Landed as one commit because the two only ever run together, and each one's Dependabot pull request went stale the moment the other merged -- two rebase cycles for a two-line diff. upload-artifact v6 -> v7 went ahead of them in #54.

Neither action is exercised by any pull request: release.yml runs on a tag and nothing else. The compatibility review below stands in for a check.

download-artifact v7 -> v8

The one real breaking change of the three:

• A digest mismatch is now an error, not a warning (digest-mismatch defaults to error).
• The action no longer unzips a download whose Content-Type says it is not a zip.

Both exist to support v7's direct (unzipped) uploads. This pipeline uploads ordinary zipped artifacts and downloads them in the same run, so the second is inert and the first is a straight gain: a corrupted transfer now fails the release instead of publishing a damaged asset.

tauri-action v0.6.2 -> v1.0.0

Eight breaking changes upstream, none of which reach this workflow:

Upstream change	Why it does not apply
assetNamePattern -> releaseAssetNamePattern, includeUpdaterJson -> uploadUpdaterJson	not passed -- the step sets only projectPath and args
Removed includeRelease, includeDebug, updaterJsonKeepUniversal, project auto-init	not passed
"will now update the name and body of existing releases"	no tagName, so this is the build-only path; the publish job still owns the release and its CHANGES.md notes
.app.tar.gz and .sig now carry the version	"Stage release assets" collects an explicit allowlist (dmg, deb, rpm, AppImage, msi, exe, msix, and the two skillkeeper-cli-* archives) that never included the updater bundles
Drops Tauri v1 and unstable v2	this app is on Tauri 2.11.5
Removed Gitea support	not used

Two v1 changes do land on this layout, and the workflow already satisfies both:

• Runner detection now fails loudly when a lockfile is present but its package manager is not installed. Enable pnpm via corepack and Install dependencies (frozen lockfile) both run before this step.
• Lockfile detection now walks up the file tree. With projectPath: apps/desktop and the only pnpm-lock.yaml at the repository root, v1 finds a lockfile where v0.6.2 found none. Worst case is a redundant install.

Verification

setup-uv v10 (#57) was verified for real rather than reviewed: docs.yml has workflow_dispatch, so it ran end-to-end on the Dependabot branch -- Install uv and Deploy docs both succeeded.

There is no equivalent for release.yml. The check for this one is a release candidate: RC tags are cut from develop, publish as a GitHub pre-release, and releases/latest/download/... -- what both one-line installers use -- never resolves to a pre-release, so an RC cannot reach users.