Reconsider update metadata for published AppImages

Is your feature request related to a problem? Please describe.

Current tagged releases publish Vicinae-x86_64.AppImage and Vicinae-aarch64.AppImage, but those files do not advertise an AppImage update feed or their GitHub Releases page. AppImage clients cannot discover a matching update, so people who use the published artifacts must find the Releases page and download a new full AppImage themselves.

I found the earlier request in #1261, which was closed because direct AppImage use might be phased out in favor of an AppDir. I am not trying to reopen that decision by stealth. The release pipeline still builds and publishes direct AppImage assets, so I think it is worth deciding whether they are supported while they remain available. If they are, update metadata would make the release artifacts work with standard AppImage update clients. If they are not, removing or clearly marking those assets as unsupported would be less confusing.

Describe the solution you would like

If direct AppImages remain a supported release format, define and test an update contract for the release pipeline:

• Embed update information in the AppImage .upd_info section. gh-releases-zsync pointed at the official vicinaehq/vicinae assets is one possible format, but the maintainer should choose the exact channel and stable asset naming.
• For each tagged release, publish one matching .AppImage.zsync sidecar for every supported architecture. The embedded update string must resolve to the same-architecture sidecar in the latest release.
• Make zsyncmake available to the packaging environment, then collect the sidecars with the AppImages. CI should fail if either expected sidecar is missing, rather than accepting the artifact glob when only the AppImage exists.
• Smoke-test the final GitHub Release with a target AppImage client or AppImageUpdate. That should determine which embedded and desktop metadata is actually required. X-AppImage-Homepage=https://github.com/vicinaehq/vicinae may help clients that use a project homepage, but it should not be treated as proof that updates work.
• Decide and document the behavior for local, pull-request, and fork-built AppImages. In particular, an image built from a fork should not silently advertise updates from the official project unless that is intentional.

Describe alternatives you have considered

• Keep manual downloads from GitHub Releases. This is the current behavior, but it leaves AppImage update clients without a usable route.
• Treat the AppDir or another installer as the only supported path. If that is the intended direction, removing the direct AppImage assets avoids shipping a format that appears usable but has no update story.
• Maintain a project-specific updater. That adds more code and maintenance than using the update mechanism already understood by the AppImage ecosystem.

Additional context

I made a reference implementation in e12d5555f559813c79fa9711a464a5c3b8102ffc, but I am deliberately not opening a pull request. This is mainly a packaging and release-pipeline policy decision, and I would rather the maintainers decide whether to support it and implement it in the form they prefer. The commit is only there as a concrete starting point if it helps.

The current release workflow already collects AppImage artifacts and publishes everything in dist/*, so a generated .zsync sidecar can flow through the existing release step once the packaging contract is agreed.