fix(snap): unfreeze Snap Store at v1.13.15 + permanent bump fix

[nelsonduarte]

Summary

The Snap Store has been silently frozen at v1.13.9 since the v1.13.10 release. Users running snap list see pdfapps 1.13.9 even after snap refresh, while the project is on v1.13.15.

Root cause

snap/snapcraft.yaml:4 had version: '1.13.9' hardcoded. The bump pipeline in .github/workflows/release.yml does include snap/snapcraft.yaml in its target list, but the inline Python script derives OLD dynamically from app/constants.py and builds every regex with re.escape(OLD).

Between v1.13.9 and v1.13.13, app/constants.py was bumped manually (commits 96ad51c, 3883dc9, 1e19f7a — each touching only app/constants.py). The other packaging files (snap, rpm, winget, aur-bin, flatpak) drifted out of sync. From v1.13.13 onward, when release.yml finally ran, OLD was 1.13.12 / 1.13.14 and the snap still said 1.13.9 — so re.sub matched nothing and silently did nothing. The workflow printed unchanged: snap/snapcraft.yaml and proceeded to tag the release.

Every publish since v1.13.10 (revisions 25-29) uploaded a snap to the Store but with the frozen version string 1.13.9. CI reported success because snapcraft upload does not fail when the version field mismatches the binary.

Fix

1. Immediate recovery: snap/snapcraft.yaml now says version: '1.13.15'.
2. Permanent: in .github/workflows/release.yml, packaging-file regexes match any semver (\d+\.\d+\.\d+) instead of the escaped OLD value, so drift no longer hides the substitution. Each target is marked required/optional; if a required file produces no match and is not already at NEW, the workflow fails loudly. Re-running with NEW == OLD is now an idempotent no-op.
3. Regression tests in tests/test_release_bump_script.py extract the inline script from release.yml and exercise the exact failure mode (constants.py at 1.13.14, snap stuck at 1.13.9). Includes a belt-and-braces check that snap/snapcraft.yaml in the repo always matches APP_VERSION.

Other stale files (out of scope for this PR)

Audit of snap/ rpm/ flatpak/ aur/ winget/ debian/ msix/ shows the same drift hit several files. The permanent fix above will repair all of them on the next release bump, but you may want a targeted follow-up:

• rpm/pdfapps.spec — 1.13.9
• winget/nelsonduarte.PDFApps.installer.yaml — 1.13.9
• winget/nelsonduarte.PDFApps.locale.en-US.yaml — 1.13.9
• winget/nelsonduarte.PDFApps.yaml — 1.13.9
• aur/pdfapps/PKGBUILD and .SRCINFO — 1.13.9
• aur/pdfapps-bin/PKGBUILD and .SRCINFO — 1.13.10
• flatpak/io.github.nelsonduarte.PDFApps.yml — 1.13.9 (already caught by tests/test_pdfapps.py::TestAuditRegressions::test_flatpak_manifest_tag_is_current, which currently fails on main for the same reason)
• msix/generate_listing_csv.py — release notes hardcoded to 1.13.9 (likely intentional per-release; verify)

Recovery procedure (post-merge)

After merge, trigger publish.yml manually with version: 1.13.15:

gh workflow run publish.yml -f version=1.13.15

The snap job will rebuild and re-upload as revision 30 with the correct 1.13.15 string.

ETA: ~8-10 min for the workflow + ~15-30 min for Snap Store CDN propagation. Users running snap refresh after that should see v1.13.15.

Validation

• python -c "import yaml; yaml.safe_load(open('snap/snapcraft.yaml'))" -> OK, version 1.13.15.
• New tests tests/test_release_bump_script.py (4 tests, all passing).
• Full pytest tests/ -> 199 passed, 1 skipped, 1 pre-existing failure (test_flatpak_manifest_tag_is_current — same root cause, listed above as out-of-scope cleanup).
• No APP_VERSION bump in this PR.