Bind libmoq_ffi from the object's own metadata, not from its header

moq-ffi publishes MoQ over QUIC behind UniFFI's C ABI, prebuilt for both
Linux architectures, which is the transport half of a call without the 440
crates that building it entails. This takes those bytes and declares them.

The bindings are GENERATED from the .so rather than transcribed from the C
header the release ships, because the two do not describe the same library:
moq-ffi's `audio` and `video` features are on by default and are off in the
Linux and Android artifacts, so the header has 230 entry points where our
object has 206, with the whole moqaudio*/moqvideo* surface among the
missing. Binding the header would have linked on a Mac and failed on both
platforms frq ships to. UniFFI embeds its interface metadata in the object,
so `just gen-moq` reads it back out and emits src/frq/moq/raw.clj — 403
entry points, none inferred: a ctype the generator does not know is reported
and left unbound rather than given a plausible width, which would be a
silent memory bug instead of a compile error.

frq.moq.uniffi is the substrate: the RustBuffer and RustCallStatus layouts,
the out-parameter wrapper nearly every call wears, UTF-8 in and out, and the
future family. Async keeps frq.av's contract rather than bending it — the
continuation tokio invokes from a thread jolt never started lives in an
auto-arena, is :collect-safe, and does nothing but set an atom, so the loop
thread polls a future exactly as pump! already polls the media plane.

Nothing moves off libjoltmoq yet; both objects are declared, and frq.moq.smoke
is what says the layouts are real -- contract version, a handle constructed
and freed, and a 29-character string that is 33 bytes on the other side.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>