Unreachable post-monomorphization error triggered by `-C link-dead-code`

I have the following code:

#![allow(dead_code)]

trait Foo {
    fn baz() {
        const { panic!() }
    }
}

impl Foo for () {}

If I build normally (using cargo build), it succeeds. If I build passing RUSTFLAGS='-C link-dead-code', Rust attempts to monomorphize Foo::baz and fails despite Foo::baz never being used:

error[E0080]: evaluation of `<() as Foo>::baz::{constant#0}` failed
 --> src/lib.rs:5:17
  |
5 |         const { panic!() }
  |                 ^^^^^^^^ the evaluated program panicked at 'explicit panic', src/lib.rs:5:17
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

note: erroneous constant encountered
 --> src/lib.rs:5:9
  |
5 |         const { panic!() }
  |         ^^^^^^^^^^^^^^^^^^

note: the above error was encountered while instantiating `fn <() as Foo>::baz`

Post-monomorphization errors (PMEs) are often used to detect error conditions at compile time that cannot be encoded in the type system proper. We do this in zerocopy 0.8 in certain APIs to ban dynamically-sized types whose trailing element type is zero-sized.

cargo fuzz builds using -C link-dead-code, and so it has been causing build failures for our users. In our specific case, it's possible to work around this because (for entirely coincidental reasons) the issue is only triggered by deprecated APIs that we can likely just remove. However, it's only luck that this hasn't caused more serious breakage for us.

I'm not sure what the right thing to do here is. From our perspective, having -C link-dead-code be more permissive would be good, but I understand why that might not be desirable for other users.

Miscellaneous

Cargo version 1.81.0.

Start with the reproducer in src/lib.rs and compare a normal cargo build with RUSTFLAGS='-C link-dead-code'; review how the compiler handles the post-monomorphization error for the unused Foo::baz implementation. Determine the intended behavior for link-dead-code, then add a regression test covering the reproducer and verify the cargo fuzz-related build scenario no longer fails.