Clipboard copy in code-server on iPad is unreliable with dragged/keyboard selections

### Is there an existing issue for this?

- [x] I have searched the existing issues

### OS/Web Information

- **iPadOS:** 26.0.1
- **code-server:** 4.105.1 (`811ec6c1d60add2eb92446161ca812828fdbaa7f`)
- **VS Code (web):** 1.105.1
- **Browsers on iPad:** Safari, Safari PWA (Add to Home Screen), Brave, Chrome
- **Access:** Tailscale with HTTPS (valid certs; no warnings)
- **Host:** code-server running in WSL2 on Windows 11 (Ubuntu)

### Steps to Reproduce

1. Open code-server in Safari
2. Open a file (I used `.py`)
3. Select code by dragging with mouse/trackpad from end to beginning
4. Press **⌘C** to copy.
5. Press the position you want to paste
6. Press **⌘V** to paste.

> **Note on selection direction:** If I select **from the beginning to the end** of the text, copy tends to work **more often**, but I then hit separate **encoding issues** (details below). If I select **from the end to the beginning** (which is common in real use), copy fails much more frequently. Details and diagnostics are in later sections.

### Expected

Copy should reliably place the selected text into the iPad system clipboard, regardless of how the selection was created. Pasting should paste the just selected text.

### Actual

The pasted text is often **not** the selection; it pastes whatever was previously on the clipboard.
Because this is **intermittent**, try the above a few times if it works once; failures are common but not 100%.

### Logs

```shell
When selecting text (end to beginning), pressing **⌘C** (fails), and pasting (pasted previously copied text, not the new text):

[18:36:01] File action: writeFile /mnt/c/Users///temp.py
[18:36:01] [File Watcher (node.js)] [raw] ["change"] temp.py
[18:36:01] [File Watcher (node.js)] [CHANGED] /mnt/c/Users///temp.py
[18:36:01] [File Watcher (node.js)] >> ignored (not included) /mnt/c/Users///temp.py
[18:36:01] [File Watcher (node.js)] [raw] ["change"] temp.py
[18:36:01] [File Watcher (node.js)] [CHANGED] /mnt/c/Users///temp.py
[18:36:01] [File Watcher (node.js)] >> ignored (not included) /mnt/c/Users///temp.py
[18:36:01] [File Watcher ('parcel')] [CHANGED] /mnt/c/Users///temp.py
[18:36:01] File action: writeFile /home//.local/share/code-server/User/History/-5a5bb3a7/entries.json
[18:36:01] [File Watcher ('parcel')] [CHANGED] /mnt/c/Users///temp.py
[18:36:01] [File Watcher ('parcel')] >> normalized [CHANGED] /mnt/c/Users///temp.py
```

### Screenshot/Video

https://github.com/user-attachments/assets/defdc0fb-6442-484e-a772-f1914b6b16e7

### Does this bug reproduce in native VS Code?

This cannot be tested in native VS Code

### Does this bug reproduce in GitHub Codespaces?

I did not test GitHub Codespaces

### Are you accessing code-server over a secure context?

- [x] I am using a secure context.

### Notes

## Additional observations

### A) Selection direction vs. encoding artifacts
- Selecting **begin → end** tends to copy **more reliably** (always so far), **but** small selections that include certain punctuation (quotes, commas, colons) can paste as **URL‑encoded text**.
- **Code line:** `print("Torch version:", torch.__version__)`
- **Example selected:** `n:", to`
- **Pasted:** `n:%22,%20to`
- When selecting **larger spans** or **multiple lines**, the URL‑encoding doesn’t appear.
- When pasting **multiple lines** that were copied during these “encoded” cases, they paste as **one line** instead of preserving line breaks.

### B) Selection method that always works (diagnostic)
- If I select by **double-click** (word) or **triple-click** (entire line) and then copy, **copy/paste always works** and I do **not** see the encoding issue.
- This is useful as a control, but it’s not how users typically select arbitrary ranges in day-to-day editing.

---

## What I’ve tried

### Copy mechanisms
- **⌘C / ⌘V** (default) → unreliable with drag/Shift+Arrow selections.
- **right‑click → Copy** → same behavior.

### Keybindings
- Custom binding of `editor.action.clipboardCopyAction` to **Ctrl+Shift+C** → still unreliable with drag selections.
- Default **⌘C** left in place to match typical usage; same results.

### Browsers
- **Safari**, **Safari PWA**, **Brave**, **Chrome** on iPad → identical behavior (expected; all are WebKit).

### Selection variants
- **End → begin** selection → fails more frequently.
- **Begin → end** selection → succeeds always (in the short time I've tried it), but introduces **URL‑encoded paste** for short spans containing punctuation.
- **Double/triple‑click** selection → **always succeeds**, no encoding issue.
- **Multiple lines / larger blocks** → encoding issue not observed.

---

## Impact

Frequent copy failures and occasional encoding artifacts make normal editing (moving code, refactoring snippets, copying short substrings) unreliable on iPad. The **Begin → end** selection is a usable workaround for now, and for the encoding issue I can select more text and delete the extra parts, but it does impact my productivity.

On a side note, this is my first issue on a public repository, so feedback on what I could do differently in the future is always welcome :)

首先，在列出的浏览器中于 iPadOS 上的 code-server 重现拖动选择、复制和粘贴步骤，使用双击和三击控件比较从末尾到开头以及从开头到末尾的选择。跟踪 VS Code web editor 使用的浏览器剪贴板路径；当任意选择都能可靠地到达 iPad 剪贴板、保留换行符且不会变成 URL-encoded 时，即视为完成。

由索引模型根据 Issue 内容生成。