v1.1.9

Pick a logo, get that logo

The launcher only used your chosen image when it was running inside Windows Terminal or
WezTerm. Everywhere else it quietly drew fastfetch's built-in ASCII Windows logo instead, so
setting a logo in the app looked like it did nothing at all.

It now detects what the terminal can actually do, says so when it cannot draw your image, and
lets you override the decision.

What changed

• Capability detection instead of a two-terminal guess. sixel: Windows Terminal
  (WT_SESSION or TERM_PROGRAM), WezTerm, foot, contour, mlterm, yaft. kitty protocol:
  kitty, WezTerm, Ghostty. Classic conhost and anything unrecognised still get the tinted
  built-in logo.

• The fallback explains itself. With a pinned default image and randomisation off, it now
  names the terminal and shows the way out instead of swapping your logo out in silence:

  FastFetch Studio: no image support detected in the VS Code terminal, so the built-in logo was drawn.
    force it: $env:FASTFETCH_STUDIO_LOGO = 'image'   (Windows Terminal 1.22+ draws it as-is)
  

• New "How the logo is drawn" setting (Random tab): Auto / Always draw the image /
  Never - always the built-in ASCII logo. Saved as logoMode in studio-state.json, and
  overridable for one shell with $env:FASTFETCH_STUDIO_LOGO (image or builtin).

A note on VS Code and Zed

Both are recognised by name so the message can say where it happened, but neither is treated
as image-capable on purpose: VS Code gates image rendering behind
terminal.integrated.gpuAcceleration, and a terminal that ignores the image bytes draws no
logo at all - worse than the ASCII fallback. Choose Always draw the image if yours is set up
for it.

Upgrading

The fix lives in the generated launcher, so it only takes effect once that file is rewritten:
open the app and click Apply & Generate, or set the new option on the Random tab.

Full Changelog: v1.1.8...v1.1.9