Light terminal themes: use the terminal's text color too

On a light background (Catppuccin Latte in Ghostty on macOS) the panes
kept palette color 0, a dark grey slab with white text. The probe now also
asks for the text color (OSC 10). Light backgrounds are used as well, with
text, borders and titles in the terminal's text color, input fields and
buttons in a light shade of it, and the active tab drawn in it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019reK4DUGYqDUjniWYJvwUW

CHANGELOG.md

@@ -2,11 +2,13 @@
 
 ## Unreleased
 
-- **The terminal's own background:** the panes used color 0 of the terminal's palette ("black"),
-  which many color themes set to a grey lighter than their background (e.g. Catppuccin), so the
-  whole program looked washed out and grey text almost disappeared. The terminal is now asked for
-  its background color at startup and that is used (with 24-bit color and a dark background). The
-  Log says which background is used and why.
+- **The terminal's own colors, light themes too:** the panes used color 0 of the terminal's palette
+  ("black"), which color themes often set to a grey that differs from their background (e.g.
+  Catppuccin), so the whole program looked washed out, and on light themes it was a dark grey slab
+  with white text. The terminal is now asked for its background and text colors at startup. Dark
+  backgrounds are used as they are; on light ones the text, borders, input fields and the active
+  tab follow the terminal's text color as well. Needs 24-bit color; the Log says which colors are
+  used and why.
 - **Smooth scrolling on huge terminals:** while an arrow key is held, the poster waits until the
   selection rests (120 ms). Every poster rewrites all of its cells, which on a terminal zoomed far
   out was more output per step than the terminal could draw, so moving through a list lagged.