[BUG] Link click-to-copy sets clipboard as application/octet-stream, breaking paste in browsers (missing wl-copy --type on 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).