Nested JS_PROP_CLASS_DEF is accepted by the stdlib builder but not materialized at runtime

[99percentpeople]

Hi,

I found a runtime issue when using JS_PROP_CLASS_DEF() inside another standard-library object.

example:

static const JSPropDef js_child[] = {
    JS_CFUNC_DEF("fn", 0, js_child_fn),
    JS_PROP_END,
};

static const JSClassDef js_child_obj =
    JS_OBJECT_DEF("child", js_child);

static const JSPropDef js_parent[] = {
    JS_PROP_CLASS_DEF("child", &js_child_obj),
    JS_PROP_END,
};

static const JSClassDef js_parent_obj =
    JS_OBJECT_DEF("parent", js_parent);

If parent is registered as a global object, accessing parent.child.fn can crash or behave incorrectly.

From debugging, it looks like top-level stdlib objects are materialized through stdlib_init_class(), but nested JS_PROP_CLASS_DEF() values are stored as normal ROM property values. JS_GetPropertyInternal() then returns the raw JSROMClass value directly instead of converting it to a real JS object.

Is nested JS_PROP_CLASS_DEF() intended to be supported? If not, should the builder reject it? If yes, I think the runtime should materialize nested ROM class/object values on first property access, using the existing stdlib_init_class() and ROM props copy-on-write mechanism