sphinx-gp-theme(pygments[light]): give Generic.Prompt + Generic.Output distinctive light-mode colours

why: User noted the light Pygments style lacks the visual distinction
dark mode (monokai) has for shell prompts (`$`, `>>>`, etc.) and
command-output samples. Dark gives:

  body[data-theme="dark"] .highlight .gp  → #FF4689  (pink, bold)
  body[data-theme="dark"] .highlight .go  → #66D9EF  (cyan)

Light's gp-sphinx-light style mapped both tokens to plain `#475569`
(slate-600) — the same colour `Name.Label` and `Generic.Subheading`
already use. Net effect: in light mode, prompts and output were
visually indistinguishable from surrounding `bold` subheadings,
losing the "prompt vs. output" cue that dark delivers via
pink-vs-cyan contrast.

User asked specifically for purple on `.gp`. Audit of every other
dark-mode override against light's mapping confirmed the same
asymmetry on `.go` (cyan in dark, generic slate in light); fixing
both to honour the broader directive: "for any dark-mode override,
ensure light has a specialized override too."

what:
- packages/sphinx-gp-theme/src/sphinx_gp_theme/pygments_styles.py:
  two `styles[…]` map entries change, with an 8-line comment block
  explaining the asymmetry that motivated the picks:
    Generic.Output: "#475569"        →  "#0891b2"        (cyan-600)
    Generic.Prompt: "bold #475569"   →  "bold #a855f7"   (purple-500, bold)

  Colour rationale:
    - #a855f7 (Tailwind purple-500) is already in the palette for
      `Name.Decorator`, `Name.Function.Magic`, `Name.Variable.Magic`
      — keeps the palette tight at 11 distinct colours rather than
      introducing a 12th.  It's clearly distinct from `#7c3aed`
      (violet-600) used for keywords, so prompts read as their own
      visual class.
    - #0891b2 (Tailwind cyan-600) is the natural light-mode mirror
      of dark's `#66D9EF` cyan choice for the same token — same
      "this is sample output, not your code" semantic cue, just at
      a luminance suited to the slate-50 background.

- tests/test_pygments_style.py:
  +2 TokenColorCase entries in `_TOKEN_COLOR_FIXTURES` so future
  drift on either token fails the parametrized
  `test_gp_sphinx_light_token_palette` rather than waiting for a
  user to notice in rendered output:
    test_id="generic-prompt-purple"  → expected_substring="#a855f7"
    test_id="generic-output-cyan"    → expected_substring="#0891b2"

- tests/__snapshots__/test_pygments_style.ambr:
  syrupy snapshot regenerated via `pytest --snapshot-update`. Diff
  is exactly the two intended lines (gp + go); no other token
  rules drifted.

The other 9 token classes the audit checked (`.k*`, `.c*`, `.s*`,
`.mi`, `.gd`, `.gi`, `.gs`, `.gh`, `.gr`) all already specialize
in BOTH modes; only `.gp` and `.go` had the gap.

Pre-commit gate: ruff/mypy/pytest 1315 passed (was 1313, +2 new
parametrized cases)/159 skipped/just build-docs all green.

Author: tony

packages/sphinx-gp-theme/src/sphinx_gp_theme/pygments_styles.py

@@ -132,8 +132,17 @@ class GpSphinxLightStyle(style.Style):
         token.Generic.Error: "#dc2626",
         token.Generic.Heading: "bold #0f172a",
         token.Generic.Inserted: "#16a34a",
-        token.Generic.Output: "#475569",
-        token.Generic.Prompt: "bold #475569",
+        # Light-mode override for `Generic.Output` and `Generic.Prompt`
+        # so they read as distinctively as their dark-mode (monokai)
+        # counterparts (cyan #66D9EF and pink #FF4689 respectively).
+        # Without these, both tokens fall through to the same `#475569`
+        # slate-600 the palette uses for `Name.Label` + `Generic.Subheading`,
+        # leaving shell prompts (`$`, `>>>`, etc.) and command output
+        # visually indistinguishable from the surrounding `bold #475569`
+        # subheadings — losing the same "this is a prompt vs. its output"
+        # cue dark mode delivers via pink-vs-cyan contrast.
+        token.Generic.Output: "#0891b2",
+        token.Generic.Prompt: "bold #a855f7",
         token.Generic.Strong: "bold",
         token.Generic.EmphStrong: "bold italic",
         token.Generic.Subheading: "bold #475569",

tests/__snapshots__/test_pygments_style.ambr

@@ -29,8 +29,8 @@
   .highlight .gr { color: #DC2626 } /* Generic.Error */
   .highlight .gh { color: #0F172A; font-weight: bold } /* Generic.Heading */
   .highlight .gi { color: #16A34A } /* Generic.Inserted */
-  .highlight .go { color: #475569 } /* Generic.Output */
-  .highlight .gp { color: #475569; font-weight: bold } /* Generic.Prompt */
+  .highlight .go { color: #0891B2 } /* Generic.Output */
+  .highlight .gp { color: #A855F7; font-weight: bold } /* Generic.Prompt */
   .highlight .gs { color: #0F172A; font-weight: bold } /* Generic.Strong */
   .highlight .gu { color: #475569; font-weight: bold } /* Generic.Subheading */
   .highlight .gt { color: #DC2626 } /* Generic.Traceback */

tests/test_pygments_style.py

@@ -107,6 +107,21 @@ class TokenColorCase(t.NamedTuple):
         token=token.Generic.Deleted,
         expected_substring="#dc2626",
     ),
+    # Distinctive purple + cyan for Generic.Prompt and Generic.Output —
+    # mirrors the dark-mode (monokai) treatment which uses pink + cyan
+    # for these tokens. Pre-2026-05-01 both fell through to a generic
+    # slate-600, leaving shell prompts and command output visually
+    # indistinguishable from `Generic.Subheading`.
+    TokenColorCase(
+        test_id="generic-prompt-purple",
+        token=token.Generic.Prompt,
+        expected_substring="#a855f7",
+    ),
+    TokenColorCase(
+        test_id="generic-output-cyan",
+        token=token.Generic.Output,
+        expected_substring="#0891b2",
+    ),
 ]