Kitty graphics: images don't render on Windows when the sender uses file-path transmission (t=f); direct transmission (t=d) works

[rp-winter]

What happens
Inside a herdr pane, opening a PNG in Neovim with snacks.nvim image support
(:e C:/Users/<me>/test.png) shows a blank buffer. :checkhealth snacks
reports ghostty detected, unicode placeholders supported, and inline images
available, so snacks believes it can render. The placeholder cells are drawn
and space is reserved, but no image appears.

Likely cause (hypothesis)
When snacks thinks it is running locally, it transmits images with the Kitty
file-path medium (t=f), sending only the base64-encoded path
(e.g. C:/Users/<me>/test.png). The image never seems to be registered, so
the placeholders have nothing to display. This looks like herdr's terminal
engine not accepting Windows drive-letter paths, or not reading local files
at all, in t=f mode.

Workaround that works
Forcing snacks into its "remote" mode so it sends the PNG bytes inline
(t=d) makes images render correctly, including inline notebook plots
(ipynb.nvim):

:lua Snacks.image.terminal.env().remote = true

Questions

• Is t=f intentionally unsupported in herdr panes, or specifically for
  Windows paths?

• If it is intentional, could herdr advertise that so clients like snacks
  fall back to direct transmission automatically?

  Environment

• OS: Windows Microsoft Windows NT 10.0.26300.0

• Herdr: 0.1.13 (herd-core 0.1.18), desktop app

• Neovim: NVIM v0.11.2 with snacks.nvim (image module enabled)

• Shell in pane: pwsh