Ship the v2 CPU tier as a delta, and bundle deps in the AppImage (deps 1.13.0)

[StuartCameronCode]

Why

The AppImage catalog picked up the 1.2.0 AppImage on its own and its test failed (AppImage/appimage.github.io#9839). The catalog launches each AppImage with firejail --net=none and OCRs a screenshot for error text. VapourBox's first act on a fresh machine is to download its deps, so it showed "Installation Failed" and the OCR read that as an error. It also warned about "linux" in the file name and the missing AppStream metadata.

This makes the AppImage carry its deps so first launch needs no network. To do that without shipping two 236 MB bundles, the older-CPU (v2) tier becomes a small delta over the main bundle.

What changes

Deps 1.13.0 (packaging only; same sources as 1.12.0)

• Each x64 platform publishes its v3 bundle under the plain name plus …-x64-v2-delta.zip (2–3 MB): the files listed under _tierFiles in Scripts/deps-expected-plugins.json, extracted over the bundle. There is no longer a full …-x64-v2.zip.
• Scripts/make-deps-delta.py cuts the delta. It fails if the two builds hold different sets of paths, or if a tier file is identical in both.
• The build-deps-* workflows build both tiers, cut the delta, gate the composed tree (SDE on Linux/Windows, load-time check on macOS), then upload.
• app/assets/deps-version.json points at 1.13.0 with "tierFormat": "delta".

App (DependencyManager)

• Each zip comes from bundled-deps/ beside the executable (sidecar hash required), then the download cache, then the network.
• On a v2 CPU it extracts the bundle, then the delta; a delta cut against a different bundle (baseSha256) is refused.
• No zip's own version.json is extracted; the app's copy stays the commit marker.
• Extraction no longer spawns a chmod per file or awaits three calls per file (a917731): first launch of the bundled AppImage went from ~130 s to ~16–22 s on linux-arm64.

Linux package

• The AppImage carries the deps zips (package-linux.sh --bundle-deps); the tarball does not.
• Renamed VapourBox-X-x86_64.AppImage / -aarch64.AppImage. The tarball keeps linux-<arch>.
• A copy of each .zsync is also published under the old name (VapourBox-X-linux-<arch>.AppImage.zsync) so 1.2.0 AppImages can still find their update.
• AppStream metadata in packaging/linux/app.vapourbox.VapourBox.appdata.xml, stamped with version, date and a tag-pinned screenshot at package time.

CI: .github/scripts/install-deps-bundle.sh composes bundle plus delta for -v2 rows, the same way the app does.

Verified

• build-deps-macos / -windows / -linux on this branch: all jobs green, including the new delta and gate jobs. Assets are on the draft release deps-v1.13.0.
• ci-test.yml and nightly.yml on this branch against those unpublished artifacts (deps_run_id): all green. The nightly -v2 rows installed bundle plus delta and ran real encodes on all three x64 platforms.
• Bundled-deps AppImage first launch, on a linux-arm64 VM (a917731).
• Local non-heavy Flutter suite.

Not yet verified

• build-linux.yml: it fetches the deps with anonymous curl, so it cannot run until deps-v1.13.0 is published. First real run is the next app release.
• The offline first launch on x86_64, on both tiers.
• The bridge .zsync: AppImageUpdate from a real 1.2.0 AppImage.
• appstreamcli on ubuntu-22.04 accepting the appdata file (the package step validates it).

Merge order

Normal CI on this PR will fail until the deps release is published, because it downloads deps-v1.13.0 by tag and the release is still a draft (the push-triggered probe-cpu-compat run failed for the same reason).

1. gh release edit deps-v1.13.0 --target main --draft=false --latest=false
2. Re-run CI on this PR, then merge.
3. Cut the next app release; both .zsync files must be uploaded beside each AppImage.
4. /retest on the catalog PR.

Before the app release, check docs/images/screenshot.png is current; it becomes the catalog's screenshot.

🤖 Generated with Claude Code