[kixelated]

Starting C consumers turned up a sequencing conflict, so this PR has no code. It rewrites the quest to wait for the cut and the generator switch.

Why it can't land yet

• The cut's proof needs this client and these docs. moq-c parity (decided 2026-10-25) ships the hand-written moq-c 0.7 at the cut, and checks "the C interop client and every doc/lib/c sample" against its release archive before the cut. It also has every m1 binding change update doc/lib/c for the hand-written crate. If the interop client moves to the generated API first, the crate that ships at the cut loses its interop coverage.
• The docs can't describe an unpublished API. doc/AGENTS.md says "Describe only what ships", and no c-v* tag ships before the cut (epic).
• Every C type name is about to change. kixelated/rust2#66 has merged, so the switch to rust2's UniFFI will rename every generated C type to CamelCase (moq_session becomes MoqSession). A port written now would have to be redone after that switch. The epic already says this line ships after the cut and after the switch. The consumers quest just never listed either one as a blocker.

Changes

• quest/m2/c/consumers.md: adds Required entries for Breaking release cut and Switch to rust2's UniFFI, with the reasons above.
• It also records a finding: the generated API covers everything the C client needs, publishing included, because the C++ interop client already uses the same moq-ffi surface in both directions.
• It notes one open gap: test/smoke/clients/c still uses the hand-written ABI.

quest check passes. Public API: none. Wire: none.

Decisions needed

1. Should this quest wait for the cut? Recommended: yes, merge this PR as is. The alternative is to port now, but then the m1 parity quest can't prove the hand-written 0.7 with the interop client, and doc/lib/c would describe a package that hasn't shipped. That would also mean rewriting m1/c's plan.
2. Should it also wait for the generator switch, or only for the cut? Recommended: wait for both. If it waits only for the cut, the port will probably have to be redone when the switch renames every type, unless the switch lands first anyway.
3. Who moves test/smoke/clients/c off the hand-written ABI? That client checks the published libmoq archive, so it can only move once the generated archive publishes, which happens after this quest. Recommended: give it to Published generated C, and narrow this quest's "nothing in the repository" goal to exclude the smoke client.
4. Should the C interop client also publish once it is ported? The hand-written ABI couldn't, but the generated API can. Recommended: no, keep the port subscribe-only. C++ already covers the moq-ffi publish path, and adding a C publish lane makes the interop matrix bigger for little new coverage.

Follow-ups

• One C name per moq-ffi item is stale. Its plan says "delete this quest once [feat(uniffi)!: name generated C types in CamelCase, GLib style kixelated/rust2#66] merges", and that PR has merged. It should be deleted, and its remaining step (reverting the MoqAudioEncoderFinished rename) moved into the generator switch quest or the epic.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code