Draw the window's own frame: no menu bar, no title bar

The File/Edit/View/Window menu is a browser's menu, and it brought
accelerators that fought the app's own shortcuts. The OS title bar is gone
too, with minimize/maximize/close drawn in the header beside the language
toggle.

Two things a frameless window has to be told explicitly, both of which fail
as a window that cannot be moved rather than as an error: the header has to
declare itself a drag region, and interactive children have to opt out of it.

Maximise state is read from the window rather than tracked from the last
button press, because the window manager can maximise on its own — a
double-click on the drag region, a shortcut, or snapping to an edge.

README.md

@@ -343,6 +343,21 @@ Bytes cross as `Uint8Array`, never as a string. TCP splits UTF-8 characters
 across chunks routinely, and decoding either half alone corrupts them; the bug
 appears only with CJK or emoji output, which makes it easy to miss.
 
+### The window frame
+
+There is no OS title bar and no application menu: the app draws its own
+controls in the header and nothing else. Two consequences that are easy to miss:
+
+- **The header is the only drag region.** A window manager will not move a
+  window whose client area never claims `-webkit-app-region: drag`, and the
+  symptom is a window that simply cannot be moved — not an error.
+- **Interactive children must opt out** with `no-drag`, or they become
+  undraggable and, on some platforms, unclickable.
+
+Maximise state is read from the window rather than tracked from the last button
+press, because the window manager can maximise on its own — double-clicking the
+drag region, a keyboard shortcut, or snapping to a screen edge.
+
 ### Terminal font
 
 The terminal uses **the desktop's own monospace font**, read from