Ensure Sparkle appcast freshness at the hosting layer

[SeoFood]

Problem

Sparkle update checks can receive a stale appcast from the GitHub Pages/CDN layer after a new release is published.

PR #891 attempted to add a timestamp through feedParameters(for:sendingSystemProfile:). End-to-end requests with different query values still returned X-Cache: HIT with the same GitHub request ID, so the query parameter does not bypass the effective GitHub Pages cache. Sparkle already uses a reload-ignoring-local-cache policy for appcast requests, so this needs to be solved and verified at the release or hosting layer.

The Sparkle 2.9.4 dependency update was handled separately in #893 and #894.

Expected behavior

Manual and automatic update checks should reliably observe a newly published appcast without relying on unsupported delegate hooks or query parameters ignored by the CDN.

Investigation

• Document the current appcast publication path and cache headers.
• Determine whether GitHub Pages propagation can be made reliable or whether the appcast should move to an endpoint with controllable caching behavior.
• Verify the actual outgoing request and response headers.
• Test the complete transition from an old appcast to a newly published release.

Acceptance criteria

• A newly published appcast becomes visible to manual and automatic checks within a documented bound.
• The solution works at the hosting or release layer and does not use timestamp query parameters as a cache workaround.
• The effective response headers and cache behavior are documented.
• An end-to-end stale-to-new appcast verification is recorded.

Related: #891

[MineraleYT]

I dug into the caching behavior to see why the client-side cache-buster in #891 wasn't working.

It turns out GitHub Pages ignores query parameters entirely when caching. I tested the appcast URL with different ?nocache=UUID values, and the CDN returned x-cache: HIT with the exact same x-github-request-id every time. It just hard-caches the XML file for 10 minutes (max-age=600). I also tried injecting a Cache-Control: no-cache header from the client side, but the Fastly/GitHub CDN ignores that too.

I checked raw.githubusercontent.com just in case, but it behaves exactly the same way (just with a 5-minute cache instead).

Since we can't force GitHub Pages to bypass the cache from the client, I've completely reverted the cache-busting attempts in my PR. Like you mentioned, if we want instant freshness, we'd have to host the appcast.xml somewhere else (like S3 or Cloudflare) where we can explicitly set the Cache-Control response headers. Otherwise, we probably just have to live with the 10-minute delay for the appcast to update.