Both themes used bg_terminal, on the assumption the name meant "the
terminal's background". It does not -- the shared Theme struct documents
it as "For terminal output blocks (currently unused, using bg_dark
instead)". The surface grok actually paints is bg_base, so GrokDay was
rendering brighter than grok itself (#f5f5f5 vs #eeeeee) and GrokNight
darker (#0a0a0a vs #141414).
GrokDay's color15 moves from bg_storm to bg (#f5f5f5): bg_storm is now
the background, so bright white would have been invisible against it.
Audited every slot in both files against the source palettes: each value
maps to a named palette color, no text color is under 3:1 on its
background, and cursor and selection overlays clear 4.5:1.
`kitten themes` treats every .conf in <config-dir>/themes as a user
theme, which the mode system's canonical store was sitting in -- so the
picker was offering three bogus entries named light, dark and
no-preference, and had been since that store was introduced.
Move the store to ./theme-modes so ./themes means only what the kitten
means by it, and repoint apply-theme-mode.sh, the kitten shim, the
run_after hook and the test at the new path.
GrokNight and GrokDay move into ./themes with the ## name/author/
license/upstream/blurb header the kitten reads, so they now show up in
`kitten themes` and `--dump-theme` resolves them.
theme-modes/dark.conf carries the #202020 theme that was already on
disk: the file had to be re-added at its new path, so that drift comes
along with it.
