OMT fixture ID mismatch on large feature IDs

[DoFabien]

While working on the TS unsigned fixes, I ran into a separate issue on some OMT fixtures: the MLT-decoded feature ID and the MVT feature ID do not line up reliably.

One concrete example is:

• tile: test/expected/tag0x01/omt/10_530_682.mlt
• layer: aerodrome_label
• embedded MLT metadata: longID = false
• ID stream: FLAT, NONE, VARINT
• decoded MLT ID: 4293407208
• MVT ID seen from @mapbox/vector-tile: 18446744073707991000
• raw MVT ID read directly : 18446744073707991528

Two important points:

• longID = false means uint32, not signed int32, so 4293407208 is a valid MLT value
• the JS MVT ID is above Number.MAX_SAFE_INTEGER, so it is not reliable enough on its own

What makes this case interesting is that the raw MVT varint can be interpreted in different ways:

• as unsigned 64-bit: 18446744073707991528
• as signed 64-bit: -1560088
• as unsigned 32-bit low bits: 4293407208

So the current mismatch looks like an interpretation problem on large IDs.

I also saw similar mismatches on other OMT layers (place, building, aerodrome_label), so this does not look isolated to one tile

I think the generated MLT fixture likely does not preserve the original ID semantics for this case

[CommanderStorm]

MVT defines IDs as uint64 => our IDs are also unsigned.

The rust decoder/encoder has this in order, the Java encoder might be a bit weird when it comes to this. Let me check