[BUG] Link click-to-copy sets clipboard as application/octet-stream, breaking paste in browsers (missing wl-copy --type on Wayland)

Bắt đầu từ trình xử lý sao chép liên kết được dùng khi một URL được sao chép từ :ClaudeCode, rồi truy vết xem nó gọi trực tiếp wl-copy hay sử dụng vim.fn.setreg("+", url). Xác minh bản sửa bằng wl-paste -l và Firefox hoặc Chromium; hoàn tất khi clipboard cung cấp text/plain và URL có thể được dán vào các ứng dụng GUI Wayland.

Description

Clicking a link in the Claude terminal (opened via :ClaudeCode) copies it to
the clipboard with a notification confirming success, but the copied content
cannot be pasted into Firefox or Chromium on Wayland. Pasting into terminal
tools (wl-paste) works fine — only GUI applications using the standard
wl_data_device_manager protocol fail to read it.

Environment

• OS: Kicksecure (Debian 13/trixie)
• Compositor: labwc 0.8.3 (wlroots-based)
• Terminal: kitty 0.41.1
• Terminal provider: snacks (terminal.provider = "snacks")
• wl-clipboard installed and confirmed working correctly for manual
  wl-copy --type text/plain calls

Steps to reproduce

1. Open :ClaudeCode, get Claude to output a URL
2. Double-click the link to copy it (plugin shows a "copied" notification)
3. Try to paste (Ctrl+V) into Firefox's address bar, or Chromium's
4. Nothing pastes; the field remains empty or unchanged

Diagnosis

Running wl-paste -l immediately after step 2 shows only:
application/octet-stream

By contrast:

• wl-copy --type text/plain "url" followed by wl-paste -l correctly
  shows text/plain, text/plain;charset=utf-8, UTF8_STRING, etc., and
  pastes into Firefox/Chromium without issue.

• A manual OSC 52 sequence sent directly to kitty (printf '\033]52;c;...')
  is also correctly typed as text/plain by kitty itself — so kitty's own
  OSC 52 → Wayland clipboard bridge is not at fault.

• Plain echo "text" | wl-copy (no --type) also produces
  application/octet-stream on this system, matching wl-clipboard's
  documented limitation:

  wl-clipboard is not always able to detect that a MIME type is textual,
  which may break pasting into clients that expect textual formats, not
  application/something. The workaround […] is to specify the desired
  MIME type explicitly, such as wl-copy --type text/plain.
  — wl-copy(1) manpage, BUGS section

This strongly suggests the link-copy code path shells out to wl-copy
without an explicit --type, hitting this known/documented wl-clipboard
limitation, rather than going through Neovim's own clipboard provider
(vim.fn.setreg("+", url)), which I confirmed produces correctly-typed
text/plain clipboard content on the same system (tested via "+yy on a
normal buffer, checked with wl-paste -l).

Suggested fix

If the link-copy handler invokes wl-copy directly, adding --type text/plain (as documented as the standard workaround for this exact
wl-clipboard limitation) should resolve it. Alternatively, routing the copy
through Neovim's vim.fn.setreg("+", url) instead of a raw external
wl-copy call would also sidestep the issue, since that path is confirmed
to type the content correctly on this system.

Happy to test a fix if useful — this was fully reproducible and isolated
step by step (system Wayland clipboard, kitty's native OSC 52 handling, and
Neovim's own clipboard provider were all individually verified to work
correctly, narrowing the issue down to this specific code path).