docs: item 10 is done, and the three GTK facts it cost are written down

todo.md's item 10 is closed with what moved, what stayed in code and why, the reading each
slice added, and the three GTK facts in invariants-gtk-and-chrome.md. The plan's table is
marked complete, with the note that the header bar went last and in one change -- pack_start
appends after whatever a file packed, so staging it by group would have reordered the bar in
an intermediate commit.

Two facts added to the invariants: a code-added header-bar child lands after the file's, so
going first means the file declares a slot (which is what header-bar.ui does for the
time-window control); and <child type="end"> is added leftwards-from-the-right, so a header
bar's end group reads the reverse of the file.

docs/claude/invariants-gtk-and-chrome.md

@@ -324,3 +324,14 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   on-screen-display control, and the size -- is one function (`layout_overlay_button()`) rather than three
   copies. The same reason keeps the math editor's palette and parameter rows in code: their count follows the
   model, not the file. `.ui` files are for the frame, and the frame is what has no count.
+
+- **A code-added child of a header bar lands *after* the file's, so going first means using a slot.**
+  `gtk_header_bar_pack_start()` appends to the start group and there is no prepend. The time-window control is
+  code -- its menu's rows come from the buffer's limits -- and belongs at the bar's head, so `header-bar.ui`
+  declares an empty `window_control_slot` box as its first start child and the code appends the control into
+  it. Packing the control straight onto the bar would have put it to the right of everything the file packed,
+  and `[udpscope] header:` (`window_button_w=130 bar_w=756`) is the reading that shows such a move.
+- **`<child type="end">` is added leftwards-from-the-right, in document order.** A header bar's end group
+  reads the *reverse* of the file: `header-bar.ui` declares menu, sidebar, math, measures, cursors and the
+  screen shows cursors, measures, math, sidebar, menu. The three comments this replaced each had it wrong
+  once, which is why the order is the file's now and a byte-for-byte diff of the probe is the check.

docs/superpowers/plans/2026-10-11-ui-files-and-gtk4-practice.md

@@ -74,6 +74,12 @@ needs a probe that proves it *loads* and that its contents match whatever drives
 | `src/ui/ui_layout.cpp` (~20 kB) | the layout editor's overlay buttons, which are positioned by code | only the buttons are template |
 | `build_toolbar` (`src/ui.cpp`, ~212 lines) | the header bar's layout, with every button still wired in code | delicate: the `[udpscope] header:` probe reads its geometry |
 
+**Every row of the table above is done or accounted for.** The header bar went last and in one change, because
+`gtk_header_bar_pack_start()` appends after whatever a file has already packed -- staging it by group would
+have reordered the bar in an intermediate commit. Its frame is `src/ui/header-bar.ui`; the overflow menu's
+rows, the window control and every handler stayed in code, and the probe's header readings are byte-identical
+before and after.
+
 **The layout editor's buttons are not a `.ui` row, and the note above is wrong about them.** Their count *is*
 the row count (one per row, one per boundary), and `GtkBuilder` instantiates a file's objects once, so a file
 can hold neither the number nor a prototype for the code to copy. What was real in that row was the