Typed decode/read_from never check the FourCC; dref parses any entry as url

[kixelated]

DecodeAtom / ReadAtom / AsyncReadAtom correctly reject a mismatched box (header.kind != T::KIND → Error::UnexpectedBox, src/atom.rs:126-129). But the typed convenience paths never check the FourCC at all, and will happily decode any box's body as T:

• impl<T: Atom> DecodeMaybe for T — src/atom.rs:46-73 (feeds T::decode at :39-43)
• impl<T: Atom> ReadFrom for Option<T> — src/atom.rs:82-104
• src/tokio/atom.rs:24-46 (async ReadFrom)

Reproduced: a 20-byte box tagged moov containing ftyp-shaped bytes — Ftyp::decode and Ftyp::read_from both return Ok(Ftyp { major_brand: …, … }) instead of UnexpectedBox(moov). Silent misparse.

A concrete in-crate consequence: Dref decodes every entry as Url without looking at the child's fourcc (src/moov/trak/mdia/minf/dinf/dref/mod.rs:21-24 calls Url::decode(buf) in the entry loop). A spec-valid dref containing a urn entry parses its name string as a Url::location and re-encodes it under the url fourcc — silent corruption; a urn with both strings fails with a misleading UnderDecode("url "); any garbage fourcc is likewise accepted as url .

Suggested fix: have the generic decode_maybe compare header.kind against T::KIND (returning UnexpectedBox), and give dref proper urn /unknown-entry handling.

Found during an extensive automated correctness review (Claude Code); the Ftyp-from-moov misparse was reproduced against the current main sources.