docs(docs-app): wire up build-time .gjs.md docs, start .md migration

[patricklx]

Summary

Follow-up to the "check whether kolay's new shadow-DOM support can replace our downstream implementation" investigation, now extended into starting the migration of docs-app's component docs from runtime-compiled .md (kolay's in-browser REPL) to build-time-compiled .gjs.md.

Why move to .gjs.md

.md docs are compiled on-demand in the browser (via repl-sdk); .gjs.md docs are compiled once at build time into real Ember components. Moving reduces runtime REPL/compile cost per page and gets these docs full type-checking via glint.

What this PR adds

kolay's vite plugin (kolay()) already forwards scope/rehypePlugins/remarkPlugins to its build-time .gjs.md compiler (undocumented in kolay's public Options type, but wired in combined.js), so no upstream change was needed. Two real gaps had to close first, both scoped to the build-time path only:

• rehypeShadowDemo silently produced empty demos. It renames each demo's placeholder <div id="repl_N"> to <carbon-shadow-demo id="repl_N">. Runtime .md grafts the compiled demo into that element by id directly. Build-time .gjs.md (kolay's gjs-md.js) instead finds the node by id and injects the invocation by string-replacing the node's literal </div> — which no longer exists once the div is renamed, so the replace silently no-ops and the demo renders styled but empty. Fixed by giving rehypeShadowDemo an opt-in { forBuildTimeInjection: true } mode that keeps an inner <div> for the injector to target (CarbonShadowDemo re-parents whatever ends up inside it regardless of tag, so the wrapper is otherwise inert). The runtime call site in routes/application.ts is untouched and emits byte-identical output.
• Two demo-fence import specifiers don't actually resolve. carbon-components-ember/components and carbon-components-ember/helpers only work at runtime because setupKolay's dynamic modules map intercepts them before real module resolution — the package's real exports only has the /index forms. Aliased both (anchored RegExps, so already-correct /index//icon specifiers elsewhere aren't affected) in vite.config.mjs. Also added a docs-support alias (new docs-app/app/docs-support/index.ts barrel) backing the ThemeSupport/didInsert imports demos use, and a scope string so <ThemeSwitcher />/<APIDocs>/<ComponentSignature>/<ModifierSignature>/<Callout> resolve at the top level of a .gjs.md file, mirroring the runtime topLevelScope.

Converted so far

tags.md and list/item.md (one flat page, one nested-folder page, to exercise both URL shapes) — verified in a real browser (not just glint/a green build) that the demo's shadow root contains real rendered component markup, compared against an unconverted .md control page in the same session. An empty demo looks identical to a known docs-app live-preview flake otherwise, so build success alone isn't proof.

notifications.md is intentionally left as .md: its demo uses setOwner() on a plain (non-Component) class to get @service injection working, which has no build-time-import equivalent without rewriting it as a real Component subclass first.

~58 .md docs remain. Recipe and gotchas recorded for follow-up work.

The original comment fix

shadow-demo-element.ts still claimed it imports the app's stylesheets into each shadow root "mirroring <Shadowed includeStyles>". It stopped doing that in 1d7bfa3 (do not add host styles), which left STYLESHEET_SELECTOR dead and the comment wrong. Shadow demos are styled anyway because component docs render <ThemeSupport /> inside the demo, emitting the Carbon stylesheets as an inline <style> within the shadow root; :root theme tokens inherit across the boundary as custom properties.

Test plan

• glint in docs-app: 20 errors, identical to the main baseline (all pre-existing, none in touched files)
• DOCS_URL=versions/main pnpm build in docs-app: succeeds
• Served the production build and browser-checked (Playwright) that 2-components/tags and 2-components/list/item render real component markup inside their demos' shadow roots, matching a .md control page
• root pnpm lint: no new errors/warnings

🤖 Generated with Claude Code

[github-actions]

📖 Docs Preview

🔗 Preview URL: https://ibm.github.io/carbon-components-ember/pr-previews/pr-743/

Built from commit 17d51ac

[patricklx]

the code blocks in docs do not have syntax highlighting. it works on main

[patricklx]

Fixed the syntax-highlighting regression (17d51acd).

Root cause: vite.config.mjs's kolay() plugin (build-time .gjs.md compiler) only registered rehypeShadowDemo in rehypePlugins. routes/application.ts's runtime setupKolay() call separately registers rehypeShikiFromHighlighter for syntax highlighting — the build-time path never got the equivalent plugin, so converted pages' code fences rendered as plain unhighlighted text.

Fix: added @shikijs/rehype's default export to kolay()'s rehypePlugins, with the same langs/theme config as the runtime setup. Since vite.config.mjs runs in Node at build time, it can use the package's self-contained highlighter creation instead of the runtime path's manual getHighlighterCore/loadWasm (which exists only to work around browser WASM loading).

Verified:

• DOCS_URL=versions/main pnpm build succeeds; every built .gjs chunk now contains shiki output (grep shiki-light on all dist/assets/*.gjs-*.js)
• Playwright, served prod build: 2-components/tags (converted, build-time path) and 2-components/notifications (still .md, runtime path — the one intentionally-unconverted control page) render visually identical multi-color token highlighting, same shiki shiki-themes classes
• glint/root pnpm lint stay at the existing baseline (no new errors/warnings)

🤖 Generated with Claude Code