fix(build): make the release actually buildable, and check it before tagging

Preparing v0.10.0 meant building the release locally first. It did not
build. Two separate defects were sitting on master, both invisible to
every gate this project has, for the same reason: nothing in
build-and-test.yml runs `tauri build`. Only a tag does. So the first time
anyone would have discovered either was a failed release.

**Tauri plugin versions had drifted apart.** Tauri refuses to build when a
plugin's Rust crate and npm package are on different minor versions:

  tauri-plugin-log     (v2.8.0) : @tauri-apps/plugin-log     (v2.9.0)
  tauri-plugin-updater (v2.9.0) : @tauri-apps/plugin-updater (v2.10.1)

Introduced by the updater and diagnostics work in this same branch --
`cargo add` took what the pinned toolchain allowed while `bun add` took
latest, and the caret ranges let them separate. cargo check, clippy,
cargo test and svelte-check all passed.

Matching upward pulled wry 0.53.5 -> 0.54.2 along with wasm-bindgen,
web-sys and webkit2gtk: the webview layer, which on Linux is the video
playback path. That is not a change to make while cutting a release, so
the npm packages are pinned down to the crates instead -- exactly, not by
caret, since the caret is what allowed the drift. The upgrade is worth
doing deliberately, with a playback check, and ci-operations.md says so.

CI now runs `tauri info`, which performs the same comparison without
building. Verified by reintroducing the mismatch and watching it fail.

**The AppImage target had never been built.** It was added earlier in this
branch because the release notes had advertised an AppImage for months
while tauri.conf.json never produced one. It does not work out of the
box: linuxdeploy carries its own `strip`, too old to parse the .relr.dyn
section modern toolchains emit, and it fails on every bundled library --

  strip: libzstd.so.1: unknown type [0x13] section `.relr.dyn'
  failed to bundle project `failed to run linuxdeploy`

Ubuntu 23.10+ links with -z pack-relative-relocs by default, so the CI
builder image fails exactly as a modern Arch host does. NO_STRIP=true is
linuxdeploy's documented escape hatch. The resulting 153 MB AppImage was
verified to be well-formed and to actually start.

Without this the release would have failed at the Linux build step --
the artifact check added earlier refuses to publish when no AppImage is
produced, which is the behaviour we want, but it would have refused a
tagged build rather than a local one.

Also: the traceability extractor now reads the tooling shell scripts that
carry TRACES comments. DR-207, DR-213 and DR-220 all had them and were
counted as uncovered because only .ts/.svelte/.rs were scanned. Listed
individually rather than globbing scripts/*.sh -- most implement nothing,
and adding one should be a decision.

DR-221.

scripts/extract-traces.test.ts

@@ -49,6 +49,11 @@ describe("isTracedSourceFile", () => {
     expect(isTracedSourceFile("src-tauri/deny.toml")).toBe(true);
     expect(isTracedSourceFile("src-tauri/rust-toolchain.toml")).toBe(true);
     expect(isTracedSourceFile("scripts/hooks/pre-commit")).toBe(true);
+    // Shell tooling is listed individually, not globbed: most scripts/*.sh
+    // implement nothing, and adding one should be a decision.
+    expect(isTracedSourceFile("scripts/check-release-artifacts.sh")).toBe(true);
+    expect(isTracedSourceFile("scripts/build-desktop-linux.sh")).toBe(true);
+    expect(isTracedSourceFile("scripts/logcat.sh")).toBe(false);
   });
 
   it("does not scan CI workflows, whose comments discuss TRACES in prose", () => {