#26040 ci(nightly-next canary): accept the feed's R2 origin so builds reach Nightly again

The NIGHTLY app hasn't been offered a build since 8b3b189. Every nightly-next item since then carries <sparkle:channel>cmux-next-dev</sparkle:channel>, and the app allows only cmux-next.

Cause. The channel itself is by design: with NIGHTLY_NEXT_DEV_RING=on (set 10-21), a new build starts on Dev, and nightly-next-verdict.yml moves it to Nightly once a scheduled canary passes it. But since #25656 the feed's enclosures point at the feed's R2 origin (files-next.cmux.com/nightly-next/next/), and the canary's pick refused any URL that wasn't a GitHub release asset. So every scheduled canary from 05:24Z on failed at "Read the feed" (for example run 40470613015: "…-4045248345901.dmg is not a nightly-next release asset"). No verdict was written, and no build moved to cmux-next.

Fix. The pick accepts the feed's own R2 origin as well as the GitHub release. Both are ours. The canary still checks Gatekeeper, the notary tickets and the DMG length before it runs the app.

Test. tests/test_nightly_next_canary_feed_origin.py runs the pick's own inline script against feeds with R2 enclosures, GitHub enclosures and foreign origins, including a lookalike host. It fails on base (2 failures) and passes here. It's wired into ci-guards' release-notary group and into test-execution.toml.

Base. main, because scheduled workflows run from the default branch.

Risk. One more accepted download origin, our own R2 domain, matched by an exact prefix.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

Summary by CodeRabbit

• Bug Fixes
  • Nightly canary updates now accept build downloads from either the cmux NEXT feed or the nightly GitHub release path. Downloads from other sources continue to be rejected. This allows canary updates to proceed when builds are published to either supported location while maintaining the existing restrictions on download origins.