https://gitlab.synchro.net/main/sbbs/-/commit/6b95aa66c0744940c58c7541
Modified Files:
src/doors/syncconquer/door/door_io.c src/doors/termgfx/stats.c stats.h termgfx_termio.c src/doors/termgfx/test/test_stats.c
Log Message:
termgfx: one spelling for the mouse mode, and say which field is the turn key

Two doors printed a "<kbd>/<x>" token in the same place on the Ctrl-S row
where x meant different things: SyncConquer's second field is the MOUSE granularity, the shared one's is the TURN-KEY model. "kitty/cell" and "kitty/nat" are a character apart and unrelated, which makes the field
worse than absent -- a reader cannot tell which door they are looking at
from the shape of it.

The turn model now says so: " kitty turn=nat". The mouse mode gets its own shared token, " mouse=px" or " mouse=cell", and termgfx_termio carries it
too -- only when the door asked for a mouse, so a keyboard-only door does
not advertise an input it never reads. Until now the termgfx doors showed
the mouse mode nowhere on the row, only in a per-report trace, so
answering "is this terminal pixel-granular?" for SyncSCUMM meant opening SyncConquer to find out.

That question has an answer worth recording: Windows Terminal does not implement DEC 1016, in either 1.24 or 1.25, so a click there is quantised
to a cell -- about 10 game pixels on a 20px cell. Nothing door-side
changes that; the systematic bias that WAS ours to fix is fixed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net