Implicit calls to `deref` and `deref_mut` are a footgun with raw pointers

I tried this code (which models library code with invariants for all valid instances of A but without all the details):

use std::ops::Deref;
use std::mem::MaybeUninit;

struct A{
    b: MaybeUninit<B>,
}

struct B{
    field: String,
}

impl Deref for A {
    type Target = B;
    fn deref(&self)->&B{
        println!("Called deref!");
        // SAFETY
        // This deref is expected to be called only outside of the current module and field b is private
        // so as long as all instances of A have it initialized before being accessible outside,
        // this code is sound.
        unsafe {
            self.b.assume_init_ref()
        }
    }
}

// Note: while this is `main`, it is intended to show code that used for
// initialization of new instance of A. I omitted wrapping of A in a module
// and using separate factory method for brewity.
fn main() {
    let mut a: MaybeUninit<A> = MaybeUninit::uninit();
    unsafe {
        let p = a.as_ptr();
        // The only way to get pointer to field of pointee.
        let b_ptr = &raw const (*p).b;
        // However, it may cause unintended calls to a deref if we are not vigilant
        // and mistakenly type name of a field of a type our pointee dereferences to.
        let field_ptr = &raw const (*p).field;
    }
}

I expected to see this happen: this code should be rejected because it causes implicit calls to Deref::deref which assumes *p to be initialized.

Instead, this happened: code compiles and prints Called deref! when executed.

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (9322d183f 2024-10-14)
binary: rustc
commit-hash: 9322d183f45e0fd5a509820874cc5ff27744a479
commit-date: 2024-10-14
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1

No source files or tests are named. Begin by reproducing the provided Rust example, then trace the compiler handling of raw-pointer field access and implicit Deref calls; done requires a decided language or compiler behavior and validation for this case.