moq-net: SUBSCRIBE_ERROR sends hardcoded 404, no spec error-code mapping

[riedlse]

Version: moq-net 0.2.14 / moq-native 0.19.13 at rev 260a3a478600bcfc39e0028670a7307ed2c28a00

What happens

Both not-found paths in the IETF publisher reject a subscribe with the literal 404:

// rs/moq-net/src/ietf/publisher.rs:532
.reject_subscribe(stream, request_id, 404, "Broadcast not found")

// rs/moq-net/src/ietf/publisher.rs:545
.reject_subscribe(stream, request_id, 404, &err.to_string())

reject_subscribe takes error_code: u64, and there is no named enum to draw from — ietf::subscribe::SubscribeError is defined as message 0x05 with a bare u64 code. TrackStatusCode { NotFound = 0x01, ... } exists in ietf/track.rs but belongs to TRACK_STATUS, so it is not the right constant for this path. So this reads as a missing mapping rather than a wrong one: 404 looks like an HTTP status borrowed as a placeholder.

Separately, Error::NotFound maps to 13 in rs/moq-net/src/error.rs:159. The net effect is that a relay built on this crate signals "not found" as 404 on the subscribe-reject path and 13 on the internal-error path, and neither is a value from the draft's registry.

Why it matters

This surfaced through the moq-interop-runner nightly. The aiomoqt client's test harness flags the code as non-spec and currently passes those cases only through an explicit compatibility branch:

ok 4 - subscribe-error # COMPAT
  message: Non-spec error code=404 accepted as 'track not found'
ok 6 - subscribe-before-announce # COMPAT
  message: Non-spec error code=404 accepted as benign 'did not buffer'

That compat path is being removed upstream of us, at which point any relay built on moq-net fails both cases against that peer. Other implementations that validate the code strictly would already be failing them.

Suggested direction

Introduce a named error-code type for SUBSCRIBE_ERROR mapped to the registered values for the negotiated draft, and use it at both call sites instead of the literal. Since registry values have moved across draft-14 -> draft-19, this probably wants to be version-aware in the same style as the existing Encode<Version>/Decode<Version> implementations rather than a single flat constant. Aligning Error::NotFound's wire value with the same mapping would remove the second inconsistency.

Happy to put up a PR if you'd like it — I'd want a pointer on whether you would prefer a version-aware enum or a simpler impl on the existing Error type.

[kixelated]

Yeah this is addressed on dev