Does .delete() on a return_value_policy::reference wrapper call the destructor? #26591

We use return_value_policy::reference() to return references to C++ member objects. We noticed that .delete() is still available on the JS wrapper, and we're unsure what it does.

Reproduction

#include <emscripten/bind.h>
#include <vector>
using namespace emscripten;

struct Inner { std::vector<float> data; };

class Owner {
    Inner m_inner{{1.0f, 2.0f, 3.0f}};
public:
    Inner& getInner() { return m_inner; }
};

EMSCRIPTEN_BINDINGS(example) {
    class_<Inner>("Inner")
        .function("size", optional_override([](const Inner& self) {
            return self.data.size();
        }));
    class_<Owner>("Owner")
        .constructor<>()
        .function("getInner", &Owner::getInner, return_value_policy::reference());
}

const owner = new Module.Owner();
const inner = owner.getInner();
inner.delete();                     // what happens here?
owner.getInner().size();            // still returns 3 — no crash
owner.delete();

What we observed

• inner.delete() marks the wrapper as deleted (isDeleted() → true)
• But the parent's member appears unaffected — no crash even after allocator pressure

What we expected from reading the source

We traced .delete() → releaseClassHandle → runDestructor → rawDestructor(ptr) which is delete ptr. Since ptr points to a member (not new'd), we expected this to be undefined behaviour. But it doesn't crash.

Questions

1. Does rawDestructor actually run for reference-returned pointers, or is there a guard we're missing?
2. If it does run, why doesn't delete on a non-heap pointer crash in WASM?
3. What is the intended contract — should JS never call .delete() on reference wrappers? Or is this .delete() only affecting the wrapper and it is safe to call it in the sense that it won't corrupt the original data structure?