Let copy-on-select copy plain text (currently always includes an HTML flavor)

[zhiland]

The idea

Give copy-on-select control over the copy format, the same way the copy_to_clipboard keybind already has one. Either let it take a format (e.g. plain / mixed) or add a separate option,
defaulting to plain for backwards compatibility (matching the original intent noted in #9397).

Why

Since #9418 changed the default copy format to mixed, copy-on-select always writes both text/plain and a text/html flavor, with no way to opt out. The keybind gained a format parameter;
copy-on-select did not.

On macOS this breaks pasting selected text into some Electron apps (Microsoft Teams, for example). Ghostty emits the selection as:

  <div style="font-family: monospace; white-space: pre;">line one
  line two
  ...</div>

with raw \n and no <br> tags. Apps that strip the white-space: pre style collapse every newline onto one line. Native macOS fields and VS Code paste fine because they use the text/plain
flavor; only apps that prefer and mishandle the HTML are affected.

Workaround today is to use Cmd+C with copy_to_clipboard:plain, but there's no equivalent for select-to-copy.

Reproduce

1. copy-on-select = clipboard (or default true)
2. Select several lines of output (just select, no Cmd+C)
3. Paste into Microsoft Teams
4. Line breaks are gone

Confirm the HTML flavor is present:

  osascript -e 'clipboard info'                   # lists «class HTML»
  osascript -e 'the clipboard as «class HTML»'    # shows the div with raw \n

Environment

• Ghostty 1.3.1 (release) and 1.3.2 tip
• macOS

Note

Distinct from #12600, which covers the copy destination (primary vs system clipboard). This is about the copy format (plain vs HTML).

[zhiland]

Duplicate of #12971, which predates this and asks for the same thing (format control for copy-on-select). Consolidating there.
I've moved the extra context (root cause and a second affected app, Teams) into a comment on that thread.
Please follow and +1 #12971.