Language residue in cgis.resolver after language-packs step 5 #604

Follow-up to the language-packs migration (#146; steps 1–5: #597, #599, #600, #601, #602). cgis.resolver imports no language pack (the engine-packs and resolver-storage allowlists are empty), but some language knowledge remains in its text, recorded in the spec's step-4/5 implementation notes:

1. Python __init__ root rule in SymbolIndex.strip_layout_prefixes (_ROOT_PACKAGE), reached from the generic resolve_layout/map_to_node_fqn for every language.
2. JS-builtins root in classify_fqn's generic tail for sources no pack reads (root == JS_BUILTINS_ROOT → STDLIB).
3. _is_dunder in the DISPATCHES pass (symbols.dispatch_edges) — a Python notion applied to every language's methods.
4. Language-named project state threaded through ResolverEngine/SymbolResolver/IndexBuilder.build kwargs (workspace_packages, tsconfig_paths, dependency_roots, npm_dependencies) and the state keys passed to packs.

Each removal changes behaviour (for a source no pack reads, for TS resolution through resolve_layout, or for the dispatch filter), so this needs a measured change: identity diff over cgis src@715cd9a, owner-api@8de2245 and ui/, with every difference explained, rather than the byte-identical bar of steps 1–5. Natural home: step 6 (gates) or the Go pilot (step 7), whichever first needs a third language to not inherit Python/TS rules.