Getting wrong type ID `0` for allocs used as fields of single-variant enum

This surfaced in a test of mir-semantics. Originally posted by @jberthold in https://github.com/runtimeverification/mir-semantics/issues/729#issuecomment-3383544004

#[derive(PartialEq, Debug)]
enum Thing<'a> {
    Thing( &'a i16, &'a u16)
}

#[derive(PartialEq, Debug)]
struct Another<'a>(&'a i32, &'a u32);

fn main() {
    assert_eq!(Thing::Thing(&1, &2), Thing::Thing(&1, &2));
    assert_eq!(Another(&1, &2), Another(&1, &2));
    println!("All assertions passed");
}

the file enum-two-refs-fail.smir.json features ty(0) as the (data) type of four allocations, but also uses 0 as the ID for function lang_start_internal.

From inspecting the data: these allocs 10-13 are referenced from other allocs (1 references 10 and 11, 2 references 12 and 13), and 1 and 2 are of type Thing<'_> , so 10 and 12 should actually just be i16, 11 and 13 should be u16, but they aren't for some reason.

Start with kmir/src/tests/integration/data/exec-smir/allocs/enum-two-refs-fail.smir.json, especially allocations 10–13 and the lang_start_internal entry. Trace how the referenced allocations receive their type IDs and how function ID 0 is represented. Done means the allocations have the expected i16 and u16 types without conflicting with the function ID, with the integration data test passing.