superplayer-moq ships one ABI from a locally built artifact: what publishing it would need

[ramesh130]

What this is

A tracked limit, not a ticket to pick up. Phase 14's MoQ module links a locally built
moq-ffi for arm64-v8a only, and is deliberately excluded from the published set (#351,
#364). This issue is where what shipping would actually need is written down, so that "unpublished"
stays a decision rather than becoming an oversight.

What is missing

• armeabi-v7a and x86_64 are unbuilt and untested. Settle whether dev.moq:moq may ship: MPL-2.0 in the native graph refuses it under the current policy #351 built arm64 alone because this host
  is Apple Silicon and its only system image is arm64. Upstream ships all three.
• No Intel-host emulator can run this, which narrows who can reproduce a Phase 14 result.
• The artifact is not reproducible by a consumer. It is built from a source checkout with
  --no-default-features, which is what subtracts the MPL-2.0 decoder crates from the graph
  (Settle whether dev.moq:moq may ship: MPL-2.0 in the native graph refuses it under the current policy #351). The Maven artifact a consumer would resolve does not carry that subtraction, so
  publishing this module against the upstream coordinate would reintroduce exactly the licence
  problem Settle whether dev.moq:moq may ship: MPL-2.0 in the native graph refuses it under the current policy #351 closed.

That last point is the real content here. The ABI gap is a build-matrix problem; the licence gap is
a policy problem, and it is the one that decides whether this module can ever publish.

What would have to be true to publish

• A reproducible build of moq-ffi with default features off, for every ABI the library targets,
  produced by something other than one developer's machine.
• Either an upstream change that makes the decoder feature opt-in rather than default, or a
  published artifact of our own with its provenance stated — at which point THIRD_PARTY.md and
  CONTRIBUTING.md's dependency policy are both back in scope.
• docs/compatibility.md's stability table and settings.gradle.kts' published set agree on the
  module's presence, which verifyCompatibilityDocument checks as a set.

Proposing the feature change upstream is adjacent to #354 and carries no work in this repository.

Blocked by

Nothing. This blocks nothing in Phase 14 either; the phase's exit criterion is a broadcast playing
on a device, and an unpublished module satisfies it.