fix(release): make the recovery path usable, and stop promising updates that do not exist

[PathGao]

Two things #561 left behind. Both are the pipeline telling the truth about itself.

1. The recovery path always reported a failure that meant nothing

publish-packages.yml has a workflow_dispatch input, and its only possible use is a tag that is already published — recovering after the snap job failed, or exercising the workflow without cutting a release. That is exactly what #561's own description asks a maintainer to do against v2.7.2.

But Chocolatey accepts a version exactly once, and markpad-app 2.7.2 has been on the feed since 2026-08-07. So every use of that escape hatch would have reported:

workflow_dispatch v2.7.2
  ├─ snap        ← the thing you actually wanted to check
  └─ chocolatey  ← fails on a duplicate that is expected, not wrong

This is the same disease #561 treated, one level along: a signal nobody can act on. There it was a failure dressed as success; here it is a non-event dressed as a failure. Both train people to stop reading.

The job now asks the feed before packing:

GET /api/v2/Packages()?$filter=Id eq 'markpad-app' and Version eq '<version>'

Asked of the feed rather than inferred from the text of a push error, and a check that cannot answer — network, rate limit — deliberately falls through to the push, which is the real gate. The point is to drop a known non-event, not to make publishing conditional on a lookup succeeding. On the release: published path nothing changes: a duplicate there is a genuine problem and still fails.

Verified against the live feed: the query returns the version row for 2.7.2 and nothing for a version that does not exist.

2. .deb and .rpm users were told they get updates

README, before:

Snap, Chocolatey, .deb and .rpm users continue to update through their distribution channels.

There is no apt repository and no dnf repository, and tauri-plugin-updater cannot replace a package-managed install. So those users have no update path at all. RELEASING.md carried the same claim in the maintainer's own runbook, which is how it survived.

The first version of this change over-corrected, and the second commit fixes it. It said "nothing in Markpad will tell you one exists", which is not true and is not even the charitable reading: Markpad does tell them, and then fails to install it. Chasing that down produced #570 — __TAURI_BUNDLE_TYPE is not patched into the Linux binary, so bundle_type() is None and .deb, .rpm and snap all take the AppImage install path, which renames a downloaded file over /usr/bin/Markpad. Both documents now say that, and point at the issue.

The Chocolatey half of the original sentence was correct and is kept. The Snap half is a live question in #562 and is untouched here.

Tests

Two assertions, both mutation-checked.

The package managers we recommend must be the ones we publish to — across three files, in both directions: the README, the download table written into every release body, and publish-packages.yml. These drifted once already and nobody noticed for three months. The drift is about to be possible again with the arrow reversed: #562 asks whether to retire the snap, and retiring it means deleting that job — doing so without touching the two documents leaves a recommendation for a channel that no longer receives anything. The test makes that deletion fail until it is complete.

The Chocolatey skip must gate the push, not merely exist.

mutation	result
snapcraft push → snapcraft-DELETED	first test fails, second passes
drop the if: on Pack and publish	second test fails, first passes
unmodified	953 pass, npm run check clean

🤖 Generated with Claude Code