fix: hero code pane ignores light theme, always dark background

[vivek7405]

Problem

On the home page hero ("Real HTML first. JavaScript only when it earns it."),
the left-hand components/like-button.ts code pane is hardcoded to a dark
editor background in BOTH themes. In light theme this reads as an unstyled
black box, inconsistent with every other code window on the same page (the
"whole stack, in three files" section) and with /docs code blocks, which
all pick up the theme automatically.

Found live on https://webjs.dev during post-merge QA of the brand/design
system PR (#1179): reproduced identically on the Railway origin
(https://webjs.up.railway.app, bypassing any CDN cache), so it is a genuine
defect in the shipped code, not a caching artifact.

Design / approach

Two other code windows on the same page (codeWindow(), used for the
"whole stack, in three files" cards) already get this right: they use
bg-bg-elev (a semantic token that flips with the theme) plus the shared
.t-* syntax-highlight classes, which already have a :root[data-theme='dark']
override in public/input.css. The hero pane should use exactly that pattern
instead of its own hardcoded override.

Implementation notes (for the implementing agent)

• Where to edit:
  • website/app/page.ts: the inline <style> block (around L161-174) has
    .stage-code { background: oklch(0.09 0.005 60); } plus
    .stage-code > div:first-child, .stage-code pre overrides forcing dark
    colors unconditionally. Delete this block. The .stage-code div itself
    (around L231, <div class="stage-code min-w-0 border-b ...">) needs
    bg-bg-elev added to its class list (matching the WIN constant used by
    codeWindow() at L95) so it participates in the normal theme flip instead.
  • website/public/input.css: around L258-268, a
    .stage-code .t-str / .t-kw / .t-fn / ... block hardcodes the same
    syntax colors used by the dark-mode override at L270-280. Delete it; the
    base .t-* rules (L250-257) plus the existing
    :root[data-theme='dark'] .t-* / @media (prefers-color-scheme: dark)
    rules (L270-280) already produce the correct light/dark colors with no
    per-component override needed.
• Landmines: the removed CSS custom properties (--code-tag, --code-attr,
  etc.) set inside .stage-code pre are NOT read by the highlight()
  tokenizer output (.t-* classes) that actually renders inside that <pre>;
  they were dead overrides layered on top of the real (also-overridden) .t-*
  rules. Confirm nothing else in app/page.ts reads those same
  --code-tag/--code-attr/--code-str vars in a way that depended on the
  .stage-code-scoped values specifically (the root-level :root /
  :root[data-theme='dark'] definitions at L118-139 remain and still drive
  the editor-mockup panels further down the page, e.g. L298+).
• Invariants: references/styling.md / AGENTS.md "Styling: Tailwind-first"
  say prefer semantic tokens (bg-bg-elev) over hand-rolled color values;
  this fix is a straightforward application of that rule to a component that
  had drifted from it.
• Tests + docs: this is website-local presentation, no framework API change,
  so no AGENTS.md / skill update needed. Verify with webjs check (website)
  and npm test (unit + browser), plus a manual light/dark screenshot check
  of the hero section (no existing test pins this CSS, per a repo-wide grep).

Acceptance criteria

• The hero components/like-button.ts pane background matches the
  "whole stack, in three files" code windows in both light and dark theme
• webjs check passes with no new violations
• npm test (unit + browser) passes with no regressions
• No leftover reference to .stage-code or its removed CSS custom
  properties anywhere in website/