fix(model): three entry constructs were dropped in silence

[mysma-9403]

This crate's whole claim is that a construct outside its subset is refused by name, never
quietly skipped. Three of them were not.

construct	what happened
<IncludeCondition>	never read — the string did not appear anywhere in the crate. An entry present only when a condition holds was read as if it were always there.
<RepeatEntry> with a <DynamicValue> count	fell through a chain that only looks for <FixedValue>, leaving repeat: None — which is also what no RepeatEntry at all leaves. The entry decoded exactly once.
a RepeatEntry or LocationInContainerInBits on an array/aggregate entry	the early return that expands into one field per leaf happened before either was parsed, so both were discarded on the way past.

Dropping these is worse than it sounds. The entry keeps its place in the container, so its bits
are still claimed and every entry behind it is still read at an offset that assumes them — the
values that come out are wrong rather than missing, and nothing says so. This is precisely
the failure the Unsupported machinery exists to prevent.

All three are EntryKind::Unsupported now, reported at load, and pushed in place rather
than left out, so a caller sees something undecodable where the bits are instead of a container
quietly one entry short.

SUPPORTED.md had four rows that disagreed with the code — including ArrayParameterRefEntry
listed as unsupported on line 94 and as handled on line 176, which contradicted itself — and
now matches.

Why the differential suite never caught any of it: no bundled definition uses one.
rg RepeatEntry testdata/ returns nothing, and IncludeCondition appears in none of the nine.
This is the shape of gap that a test suite built from real mission files cannot close.

182 tests, all 9 differential cases still agree with the reference, fmt and clippy clean, and
the 1.85 floor was checked locally this time rather than discovered in CI.