feat: v2.7.6 — edit users in one form, Settings → Account, display names, copy over plain HTTP

- Users page: one Edit user form (display name, email, role, active, a new or
  generated password, workspaces given or taken back, sign out everywhere),
  validated as a whole before anything is written (PATCH /api/users/:id,
  GET /api/users/:id); users.display_name/email added migration-safe.
- Settings → Account for every signed-in user: profile, own password (the
  current one required, this login kept), sign out other devices
  (/api/me/account, /api/me/password, /api/me/sign-out-others; login cookie
  only, never a pane token).
- Display names wherever a person is named (sidebar, workspace owner groups,
  Users page and audit log); owner_display_name / reader_display additive.
- Users page: admins add and remove Claude/Codex pool accounts.
- Folder browser: an admin with their own Linux account opens in their home;
  the "Server folder" tick opens the host's (never remembered).
- AI Proxy: "Config 9router" beside Add profile when 9router is installed,
  opened on the dashboard's own host (GET /api/ai-proxies/9router).
- Terminal: a tmux selection reaches the clipboard over plain HTTP too
  (writeClipboard's textarea fallback, focus handed back).
- Chat: a file the session touched outside the workspace previews
  (GET /api/sessions/:id/file).
- install-system: `!requiretty` only when visudo accepts it (sudo-rs on
  Ubuntu 25.10+ rejects the setting).
- openapi.yaml regenerated; docs (API, SERVER-MODE, LANES) updated.

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

client/src/components/run/TerminalView.tsx

@@ -32,7 +32,8 @@
  * (OSC 52 — tmux's default `set-clipboard external` passes its own
  * copy-mode selections on; a CLI's OSC 52 inside the pane is not) lands in the browser
  * clipboard (`@xterm/addon-clipboard`, write-only: no program in the pane may
- * READ the user's clipboard). While the socket is down a "Reconnecting…"
+ * READ the user's clipboard) — over plain HTTP too, through `writeClipboard`'s
+ * textarea fallback. While the socket is down a "Reconnecting…"
  * overlay says keystrokes are not reaching the pane; resizes reach tmux at
  * most every 150 ms. Several browsers on one pane share ONE size: the server
  * names a driver (see pty-attach.js) and the others FOLLOW — their xterm takes
@@ -59,6 +60,7 @@ import "@xterm/xterm/css/xterm.css";
 import { useTheme } from "../../hooks/useTheme";
 import { terminalThemeFor } from "../../lib/terminalTheme";
 import { api } from "../../lib/api";
+import { writeClipboard } from "../../lib/clipboard";
 import { notePaneFocus, registerPane } from "../../lib/panePaste";
 import { attachImeInput } from "../../lib/imeInput";
 import { TERMINAL_FONTS, readTerminalFont } from "../../lib/terminalFont";
@@ -85,9 +87,11 @@ const clipboardProvider: IClipboardProvider = {
   // tmux names no selection (`52;;<b64>`), a CLI usually `c`: both are the
   // clipboard. An empty write (a "clear") is ignored.
   writeText: (_selection, text) => {
-    // Silent and best effort: no toast per copy, and on a non-secure origin
-    // (no Clipboard API, no user gesture for a fallback) it simply does nothing.
-    if (text) void navigator.clipboard?.writeText(text).catch(() => undefined);
+    // Silent and best effort: no toast per copy. On a non-secure origin
+    // (`http://<lan-ip>`, no Clipboard API) writeClipboard falls back to the
+    // textarea copy, which the browser allows while the drag that made the
+    // selection still counts as the user's gesture.
+    if (text) void writeClipboard(text);
   },
 };