Ghostty × Yazi theme sync

Yazi follows the terminal palette for much of its interface, then breaks the illusion in two places: reverse-video hover bars can become neon blocks, and syntect code previews use a separate theme that does not follow the terminal at all.

Hand-authored flavors solve that for popular themes. These tools solve it for whatever Ghostty is actually running, including built-in themes, custom themes, and included configuration.

Both implementations call `ghostty +show-config` and parse the resolved colors rather than duplicating Ghostty's theme lookup and include rules. One stable input contract covers every theme source Ghostty already understands.

The transformation changes only the Yazi surfaces that fail to follow the palette well. It leaves the rest of the preset alone and builds a TextMate theme from the same colors for code previews.

The Lua plugin applies colors directly to Yazi's live theme on every launch and refreshes a cached TextMate file before the first preview. It is the set-and-forget path.

The Python CLI writes a complete `flavor.toml` and `tmtheme.xml` that can be read, diffed, and versioned. It also installs an event-driven launchd or systemd watcher, making it a better fit for declarative dotfiles and static configuration.

The implementation does not assume every Yazi theme surface behaves the same way. Live theme-object mutations affect the current UI, while the asynchronous preview path requires a stable theme file. The split design follows that observed boundary and keeps the pure parsing and rendering modules testable without launching Yazi.