Handle duplicate dev builds when two channels resolve to the same version

[bschwedler]

When a preview devVersion and a daily devVersion for the same image resolve to the same version string, bakery currently builds both as distinct targets. This happens for Workbench today — both channels default release_branch to "latest" and hit the same URL — but it can also happen if two entries explicitly share a release_branch.

The consequences:

• Identical images built twice, with daily and preview floating tags pointing at the same digest.
• In CI, the extra build pushes overwrite tmp:latest an additional time, orphaning more image digests from the tag and increasing the number of goss test runs that must fetch images by raw digest (which currently fails due to Docker's signature validation behavior for single-arch manifests).

Bakery should detect when two devVersions within the same image resolve to the same version and handle the case explicitly rather than silently building duplicates.

[bschwedler]

The specific case that led to this was the following URLs both resolving to 2026.06.0+242.pro1

• https://dailies.rstudio.com/rstudio/latest/index.json
• https://dailies.rstudio.com/rstudio/blue-plumbago/index.json

We use the first to resolve the daily builds, but since Workbench is currently between branching for release and creating the release, so they both resolve to the same version.

[bschwedler]

The duplicate-UID guard from #553 keys on the UID, which now includes the channel. So daily and preview at the same version produce distinct UIDs and slip past it. The two builds are byte-identical (same version, same .dev-{version} subpath, same Containerfile). They differ only by the floating channel tag.

Four ways to handle it:

1. Collapse to one build carrying both channel tags (recommended). When multiple dev channels resolve to the same version, build once and apply every channel's floating tag, so daily and preview both point at the one image. This is semantically correct. The image is identical, so it should carry both channel aliases. No wasted build, one temp-registry push, one goss run, and both floating tags stay current. The cost is that the channel-to-tag model is single-valued today, so it needs a channel set plus a precedence rule for the canonical identity.

2. Keep the higher-priority channel, skip the duplicate. Detect the collision and drop one channel (say preview wins and daily is skipped). Simple, but it leaves the dropped channel's floating tag stale even though that channel's head genuinely moved to this version. Wrong for anyone tracking :daily.

3. Hard-fail on the collision. Extend the guard to also catch same-version-across-channels and raise. Cheap, but it breaks dev builds during a normal recurring window every release cycle, from branch cut to release publish. Wrong as the primary fix. Fine only as a safety net behind option 1.

4. De-duplicate at the registry/merge layer. Push and run goss once by digest. This treats the symptoms (the tmp:latest overwrite, orphaned digests, goss-by-digest failures) but still builds twice and is more fragile.

Recommendation: option 1, with option 3's collision detection kept as a guardrail for cases collapse can't handle.