web: focus textarea on paste + better fallback for iOS clipboard

Old code immediately showed 'clipboard read denied' if navigator.clipboard
.readText() rejected, even when iOS Safari was still showing the Paste
button. New behavior: focus the textarea first so the user has an
unambiguous target for long-press-paste, then try readText, then
execCommand('paste') as belt-and-suspenders. Only show the denial
message if all three failed.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

server/web/index.html

@@ -204,8 +204,28 @@
 
   // ── Send ──────────────────────────────────────────────────────────────
   $("pasteBtn").addEventListener("click", async () => {
-    try { $("out").value = await navigator.clipboard.readText(); status("pasted from clipboard", "ok"); }
+    const ta = $("out");
-    catch (e) { status("clipboard read denied — paste manually", "err"); }
+    ta.focus();
+    // Try a few strategies in order — iOS Safari is picky.
+    try {
+      const text = await navigator.clipboard.readText();
+      if (text) {
+        ta.value = text;
+        ta.setSelectionRange(text.length, text.length);
+        status("pasted from clipboard ✓", "ok");
+        return;
+      }
+    } catch (e) { /* fall through */ }
+    // Fallback: try execCommand paste while focused (deprecated but iOS still honors it)
+    try {
+      if (document.execCommand && document.execCommand("paste")) {
+        if (ta.value) {
+          status("pasted from clipboard ✓", "ok");
+          return;
+        }
+      }
+    } catch (e) {}
+    status("clipboard read denied — long-press the box to paste", "err");
   });
 
   $("sendBtn").addEventListener("click", async () => {