Mp4: Update chunk offsets when creating udta/meta atoms

[jfietz]

Disclosure, per the note in CONTRIBUTING.md: I ran into this on my own media library and worked out the symptom myself, but I used AI for narrowing it down to these specific branches. PR and the tests were done with AI assistance, and I have reviewed and reproduced all of the results below. Happy to adjust the approach or trim the tests if you would prefer something smaller.

---

Fixes chunk offset handling when the tag container has to be created.

update_offsets was only reachable from save_to_existing. The two branches in
write_to that create the container - "No udta atom found, creating one" and
"No meta atom found, creating one" - spliced their bytes into moov without
touching stco/co64. For files where moov precedes mdat, that shifts the
media data while every chunk offset keeps pointing at the old location, leaving
the stream undecodable.

Both call sites now call update_offsets before the splice, while the offset
atoms are still at their pre-splice positions.

Adds three regression tests:

• create_udta_updates_chunk_offsets and create_meta_updates_chunk_offsets,
  over minimal hand-built MP4s, one per creation path.
• create_udta_updates_chunk_offsets_in_real_file, over a new
  faststart_no_udta.mp4 asset - a real H.264/AAC file that the current
  implementation corrupts. Generated from ffmpeg's synthetic testsrc/sine
  sources, so it carries no copyrighted content.

All three fail on main and pass with the fix. cargo test, cargo fmt and
cargo clippy are clean.

closes #686

---

Unrelated to this change, but noticed while running the checks in
CONTRIBUTING.md: cargo clippy --all-targets fails on current stable for
reasons that predate this branch. CI does not catch it, since it runs
cargo clippy --all-features without --all-targets and so never lints the
examples. #689 fixes that separately.