[ghosthack]

Summary

Several modern terminal emulators (Ghostty, Contour, foot) implement a VT
extension where a program queries the host terminal's light/dark color
preference with CSI ?996n and gets back CSI ?997;<n>n (0=unknown,
1=light, 2=dark). Some CLIs now send this to pick their own theme.

JediTerm currently treats this as an unrecognized DEC-specific Device
Status Report and silently drops it (Don't support DEC-specific Device Report Status), so the querying program never gets an answer.

This adds support for it:

• Terminal.getColorMode() — new default method, returns UNKNOWN unless overridden
• TerminalColorMode — new enum (UNKNOWN/LIGHT/DARK) carrying the reply code
• JediTerminal.setColorMode(...) — lets the embedding application report its actual theme
• JediEmulator answers CSI ?996n with CSI ?997;<code>n instead of warning and dropping it

Also improved the existing warning for any other unrecognized
DEC-specific DSR to include ControlSequence.getDebugInfo() (parsed args

• raw ESC[...] sequence) instead of a generic message, which is how I
  found the ?996n case in the first place — useful for diagnosing future
  unsupported sequences without needing DEBUG-level logging enabled.

Fully additive/backwards compatible — no existing method signatures changed, getColorMode() is a default method, getColorMode/setColorMode only apply if the embedder opts in.

Test plan

• ./gradlew :core:compileJava :core:compileKotlin against current master
• Verified against a real-world repro: a CLI running inside a JediTerm-backed pty sending CSI ?996n, confirmed the correct CSI ?997;<n>n reply is now sent based on the embedding app's reported color mode