Record at the code what W5 measured about the list

src/Bws.Gui/Themes/Marks.xaml

@@ -76,6 +76,18 @@
         word is translated - the code is not, and a trigger matching on "Running" would quietly
         stop matching the day a second language file appears - the row would just lose its
         colour, with nothing anywhere saying why. This project has had four of those.
+
+        EVERY TRIGGER HERE CARRIES A BINDING OF ITS OWN, AND THAT WAS MEASURED AND KEPT - 2026-09-29.
+        WPF keeps one binding expression per Binding OBJECT per element, so five triggers are five
+        expressions on every status mark and seven on every start mark - thirteen of the eighteen
+        bindings a row carries. Handing each mark's triggers ONE shared Binding from this dictionary
+        (a keyed Binding and {StaticResource} in each trigger) takes a row to three, keeps every
+        trigger and setter as it is, and was built on a trial branch that day. The time did not
+        move: the list's answer to a query and the processor per scroll step came out the same
+        within their spread, interleaved runs of each. The external report of 2026-09-28 proposed
+        another way to the same count - one binding into Tag and plain Triggers - which also needs
+        MarkDistinctionGuards rewritten, and it was not built once the count itself had bought
+        nothing. Not worth a change to the product, by the owner's decision on the numbers.
     -->
     <Style x:Key="StatusMark" TargetType="Ellipse" BasedOn="{StaticResource MarkShape}">
         <Style.Triggers>

src/Bws.Gui/ViewModels/MainViewModel.Scope.cs

@@ -32,6 +32,15 @@ public sealed partial class MainViewModel
     ///
     /// Setting it to what it already is does nothing at all, so a radio button re-announcing itself
     /// cannot throw somebody's selection away.
+    ///
+    /// <b>A move is removals and insertions rather than one reset, and that was measured and kept on
+    /// 2026-09-29.</b> Timed inside the process with nothing polling the window, the kept preferences
+    /// written afterwards included: Services to Drivers and back a median of 54-68 ms, every move to
+    /// or from Everything 33-54 ms - about what a query costs. A reset is allowed only between
+    /// Services and Drivers, which share no row, so it could take at most the difference between
+    /// those two lines, and on a query the same reset took nothing at all (see RowList.Reconcile).
+    /// Anywhere else it would drop the rows the two lists share together with their selection and
+    /// scroll, which `A10` forbids. Kept by the owner's decision on those numbers.
     /// </summary>
     public EntryScope Scope
     {
@@ -87,6 +96,13 @@ public EntryScope Scope
     /// <b>In this file since 2026-09-15</b>, when MainViewModel.cs stood one line under the ceiling
     /// and the positions of the switch needed telling here that their counts moved - the counts
     /// are cut with the scope, so the reading that recuts is the reading that has to say so.
+    ///
+    /// <b>Called on a tick that found entries only MOVED too, where no scope can have changed, and
+    /// that was measured and kept on 2026-09-29.</b> The external report of 2026-09-28 proposed
+    /// skipping the recut and the three positions there. Timed inside the process over 311 and 774
+    /// rows, this whole method is a median of 0.7-1.0 ms against 0.3-0.5 ms for Apply alone, so the
+    /// proposal could save half a millisecond a tick, and a second path would be one more way for a
+    /// scope to go stale.
     /// </summary>
     private void Reread()
     {

src/Bws.Gui/ViewModels/RowList.cs

@@ -171,10 +171,19 @@ public void Reconcile(IReadOnlyList<EntryRow> wanted)
         // ONE RESET INSTEAD OF HUNDREDS OF REMOVALS WAS TRIED HERE AND DID NOTHING - backlog 153,
         // measured 2026-08-11. Swapping 764 separate removals for one reset left the keystroke at the
         // same 143 ms in the window, because this method and the filter together are under 3 ms and
-        // about 140 ms is the list's own reaction to any change at all. It was taken back, since it
-        // also broke the promise above about selection and scroll for no measured gain. Written here
+        // the rest is the list's own reaction to any change at all. It was taken back, since it also
+        // broke the promise above about selection and scroll for no measured gain. Written here
         // because the idea is obvious from this code alone - the external performance report of
-        // 2026-09-28 proposed it again for that reason. What is still open is where the 140 ms goes.
+        // 2026-09-28 proposed it again for that reason.
+        //
+        // WHERE THE REST GOES WAS SETTLED 2026-09-29, and there is nothing left to take on this side.
+        // Timed inside the process with nothing polling the window, the answer to a query over 774
+        // entries is a median of 25-55 ms - the 143 was measured through UI Automation, and a third of
+        // the interface thread's work then was the window answering the probe. Profiled with managed
+        // stacks and again with kernel samples, this code and everything else of ours is 2-4% of it.
+        // The rest is WPF taking a new set of rows: layout, bindings, render preparation and the
+        // collection change. Two thirds of the bindings on a row were removed on a trial branch the
+        // same day (see Themes/Marks.xaml) and the time did not move.
 
         // BUILT ON EVERY CALL, the tick included - unlike `present` below, which waits until
         // something is out of place. About eight hundred hash insertions a second on a quiet machine