Encountering the type length limit ICEs Miri

The following program ICEs Miri when invoked with -Zenforce-type-length-limit:

#![type_length_limit = "8"]
fn main() {}

Miri reports:

Miri caused an ICE during evaluation. Here's the interpreter backtrace at the time of the panic:
note: the place in the program where the ICE was triggered
   --> /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:140:5
    |
140 |     panic::catch_unwind(move || unsafe { init(argc, argv, sigpipe) }).map_err(rt_abort)?;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: BACKTRACE:
    = note: inside `std::rt::lang_start_internal` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:140:5: 140:70
    = note: inside `std::rt::lang_start::<()>` at /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:158:17: 163:6

error: internal compiler error: src/tools/miri/src/diagnostics.rs:324:17: This error should be impossible in Miri: encountered overly generic constant

thread 'rustc' panicked at src/tools/miri/src/diagnostics.rs:324:17:
<backtrace to Miri's error reporting code, not relevant>

I'm filing this here because I'm pretty sure the problem is that the core interpreter logic does not handle the new failure path out of Instance::try_resolve correctly.

rustc 1.81.0-nightly (c6727fc9b 2024-07-12)
binary: rustc
commit-hash: c6727fc9b5c64cefa7263486497ee95e529bd0f8
commit-date: 2024-07-12
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

Start with the minimal program in the issue and invoke Miri with -Zenforce-type-length-limit to reproduce the ICE. Read src/tools/miri/src/diagnostics.rs around line 324 and trace the failure path from Instance::try_resolve; done means this case no longer triggers an internal compiler error.