iloc encode is hardwired to version 0: construction_method lost, extents truncated

[kixelated]

src/meta/iloc.rs decodes versions 0/1/2 but encode_body_ext (iloc.rs:134-155) is hardwired to version 0 semantics, silently discarding or truncating data on round-trip:

• construction_method is never written (v0 has no field for it). An iloc decoded from a v1/v2 HEIF/AVIF with construction_method = 1 (idat-relative — standard for grid/overlay items) re-encodes as v0 with file-offset semantics; extent offsets then point at the wrong data. Round-trip corruption for common AVIF files.
• Extent offsets/lengths truncated to u32 (offset_size/length_size hardwired to 4, iloc.rs:174,180) for >4 GiB values — note base_offset does widen to 8 bytes when needed (:126-131), but extents don't.
• item_reference_index always dropped (index_size hardwired to 0, :166-171).
• Silent u16 truncation of item_locations.len() (:144), item_id (:150 — v2 decode can legitimately produce ids > 65535), and extents.len() (:164).

Each of these should either bump the encoded version / field sizes to fit the data, or return an error — not silently emit a structurally valid but semantically wrong box.

(The decode-side panic!s on invalid size fields in this same file are filed separately.)

Found during an extensive automated correctness review (Claude Code); verified against the current main sources.