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/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