Ignore the daemon's dummy initial frame when sizing the PTY

[dakra]

Problem

With an Emacs daemon + client frame, killing the buffer that was selected when M-x ghostel was started (e.g. *scratch*) resets the PTY to 79x22 (issue #504).

The daemon keeps an invisible ~80x24 initial frame whose sole window shows *scratch*. Killing that buffer substitutes the ghostel buffer into that window. Both ghostel's own resize path (ghostel--windows with all-frames) and core's window--adjust-process-windows collect windows across all frames, so window-adjust-process-window-size-smallest clamps the PTY to the dummy window's 79x22 body.

Note that frame-visible-p and terminal-live-p are both t on the dummy frame, so visibility can't be used as a filter; the reliable test is (and (daemonp) (eq frame terminal-frame)) — Vterminal_frame is assigned exactly once at startup, so client tty frames are never affected.

Fix

• ghostel--daemon-dummy-frame-p: identifies the dummy frame.
• ghostel--windows now skips windows on it — fixes the clamp in ghostel--adjust-size and keeps ghostel--get-render-window/anchoring off the dummy frame.
• ghostel--adjust-process-window-size drops dummy-frame windows and delegates to the standard sizing function; installed as the process's adjust-window-size-function on both PTY spawn sites (ghostel--spawn-pty, ghostel-compile). The previous (process-put proc 'adjust-window-size-function nil) was a no-op — core falls back to the global window-adjust-process-window-size-function on a nil property, so core was resizing the elisp PTY with an unfiltered all-frames window list.

If the buffer is shown only in the dummy frame, the window list is empty and the sizing function returns nil, leaving the PTY size alone.

Verification

• 3 new ERT tests (elisp group).
• Live daemon repro (daemon + 200x50 tty client): PTY stays 47x199 after killing *scratch* (was 22x79), stty size confirms; normal window resizes still track on both the native-PTY and elisp-PTY (ghostel-use-native-pty nil) paths.

For the record: eat exhibits the identical bug (verified live), and core's window--process-window-list walks all frames, so this is arguably also an upstream Emacs issue.

Fixes #504