ci(mobius): follow mobius main now that the producer stack has landed

[justinchuby]

Mobius metadata packages currently cannot pass for anyone, on any PR, regardless of content.

git fetch ... +refs/heads/justinchuby/catalogue-diffusion-builds*:...
The process '/usr/bin/git' failed with exit code 1   (x3, then error)

.github/workflows/mobius-producer-conformance.yml:28 checks out onnxruntime/mobius at justinchuby/catalogue-diffusion-builds. git ls-remote confirms that branch no longer exists. The job triggers on every pull_request, so it is a blanket false red — it is the only failure on #1747, and one of the reds on #1764 and #1729.

Why now

The step's own comment stated its exit condition:

# Stacked with mobius#538 until its image/video workflow producer lands.

mobius#538 merged today at 16:53 UTC ("Support compact SD and complete video diffusion workflows") and its branch was deleted on merge. That is why this went red today rather than degrading gradually. The stacking condition is satisfied, so the pin comes off.

Verified, not assumed

I did not just swap the ref and call it fixed — pointing at a branch that lacks the producer would only trade a fetch failure for a script failure.

• mobius#538's merge commit b9c90433 compares identical to mobius/main — ahead_by: 0, behind_by: 0. So following main today fetches byte-equivalent content to what the deleted branch carried. This is a ref change, not a content change.
• All three paths the job consumes exist at mobius/main: tests/generate_onnx_genai_validation_packages.py, tests/compare_onnx_genai_validation_packages.py, and the tests/fixtures/onnx_genai_workflows fixture directory.
• YAML parses; the resolved ref is main.

The real verification is this PR's own run of the job, since the failure is entirely in CI and cannot be reproduced locally. If it does not go green here, the diagnosis was incomplete and I would rather find that out on this PR than on someone else's.

Tradeoff, stated rather than hidden

ref: main floats. An upstream commit can redden this repo with no local change — the same class of externally-caused red I am removing here.

A SHA pin would eliminate that, at the cost of the job no longer conforming against the current producer, which is the entire purpose of a producer-conformance check. Tracking main is the intent of the job, and its failure mode is an actionable red rather than a permanent one. If the upstream churn turns out to be noisy in practice, pinning-with-a-bump-process is the fallback, but that should be driven by observed churn rather than pre-emptively.

Not addressed

This does not touch the other reds on #1764 (inherited E0599 from the RegisteredMemoryContext::device breakage, fixed on main by #1762 — those need a rebase) or #1729 (six genuine reds across Windows, macOS, and CUDA).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.19%. Comparing base (9463302) to head (38f7008).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1765      +/-   ##
==========================================
- Coverage   80.67%   80.19%   -0.48%     
==========================================
  Files         411      411              
  Lines      198661   198661              
  Branches   198661   198661              
==========================================
- Hits       160267   159321     -946     
- Misses      32972    33920     +948     
+ Partials     5422     5420       -2     

Flag	Coverage Δ
cli-ort-linux	72.47% <ø> (ø)
cli-ort-windows	72.06% <ø> (+0.09%)	⬆️
mlas	85.20% <ø> (-0.14%)	⬇️
offline	80.32% <ø> (-0.50%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.