jsref: generalize sidebar nesting for member pages with sub-pages

[caugner]

Background

In #728, Proxy/Proxy/* handler traps are nested under the Proxy() constructor entry in the JS reference sidebar. The implementation is Proxy-specific: a handler_methods field on JSRefItem, populated only when obj == "Proxy" by walking get_sub_pages for Proxy/Proxy.

Idea

Constructor / method / property pages can have their own sub-pages, and those should nest below the parent entry in the sidebar — regardless of which class they belong to. Today this matters for:

• Proxy/Proxy/* — handler traps as sub-pages of the constructor (handled in fix(jsref): nest member sub-pages in the JS reference sidebar #728 via a special case)
• Intl/Segmenter/segment/Segments (and Segments/containing, Segments/[Symbol.iterator]) — a method whose return-type class is documented as a sub-page. Currently surfaced as a separate sidebar item via special cases in slug_to_object_name and GROUP_DATA in crates/rari-doc/src/sidebars/jsref.rs.

Possible approaches

1. Recurse get_sub_pages in JSRefItem::from_obj_str, attach sub-pages as MetaChildren::Children to each entry. Explicit, keeps the existing rendering path, more code.
2. Use MetaChildren::ListSubPages { nested: true, depth: None } on every entry. Minimal code (delegates fetching + rendering to the sidebar layer), but nested <details> rendering depends on fix(sidebar): render nested subpages as details #654.

Either approach should also retire the Intl/Segmenter/segment/Segments special case in slug_to_object_name and get_group.

Related

• fix(jsref): nest member sub-pages in the JS reference sidebar #728 — Proxy-specific nesting that this would generalize
• fix(sidebar): render nested subpages as details #654 — <details> rendering for nested listSubPages, prerequisite for approach (2)