fix(detect): read terminal env from frame for emacs --daemon (#15)

`kitty-gfx--kitty-detect' and `kitty-gfx--sixel-detect' read TERM,
TERM_PROGRAM, TMUX, KITTY_PID, and the WT_* markers via
`(getenv VAR)' -- the process-level lookup.  Under
`emacs --daemon' / `emacsclient -t', the daemon process inherits
the launcher's env (often `TERM=dumb' from a systemd unit, no
TMUX, no TERM_PROGRAM); the *attached client* env lives on the
new frame's `environment' parameter.  As a result, every detect
call sees daemon env and reports "terminal not supported" even
when the client is attached from a fully sixel-/kitty-capable
terminal inside tmux.

Note `(getenv VAR FRAME)' only consults the frame env (no
process fallback), and `(getenv VAR)' only consults the process
env first (then the *selected* frame's env).  Neither alone gives
the desired prefer-frame-then-process semantics.  Add a small
helper `kitty-gfx--frame-getenv' that does, and route both detect
functions plus `kitty-gfx--tmux-sixel-supported-p' through it.

For TERM specifically also consult the frame's `tty-type'
parameter, which is set by `server-create-tty-frame' and is the
canonical TERM emacs uses for this frame -- preferred over the
env value when the latter is missing or `dumb'.

Repro before this patch (Linux, ghostty + tmux, emacs daemon):

    *kitty-gfx-debug*:
      kitty-detect: nil (KITTY_PID=nil TERM_PROGRAM=tmux)
      sixel-detect: nil (TERM=dumb TERM_PROGRAM=tmux TMUX=yes
                         tmux-ver=3.6 tmux-ok=yes WT=no)
      mode: terminal not supported, aborting enable

After the patch the detectors read the frame env, so TERM
resolves to the actual `tmux-256color' / `xterm-kitty' / etc.
and the matching backend is picked.

Behaviour unchanged for non-daemon emacs: when the frame has no
`environment' parameter, `kitty-gfx--frame-getenv' falls back to
the process env directly.

0 files changed, 0 insertions, 0 deletions