memory: correct a review point we got wrong, rather than leave it to be re-asserted

We read design-dev's 'SET order' as 'the order they were set in' and told him it
was already (created, id). He meant the SET's order — by tile number — which
genuinely differs: flag #15 then #07 and today's panel lists #15, #07 while his
tray lists #07, #15.

His rule is also cleaner than the one we proposed. The flag set sorted by its
target's position in sorted(rel) is a total order needing no tie-break at all,
because rels are unique. The memory row now says so explicitly and tells the
next session not to re-raise the point.

Round 1's booth is kept; he releases it once the flow ask is ruled.

persistent-memory.md

@@ -67,19 +67,28 @@ _As of 2026-09-22:_
   arc**, **plain-and-direct copy**, **no emblem**. He withdrew his own round-1
   `svos` ask as superseded — he did NOT answer anything on the operator's
   behalf.
-- ⚠ **`booth-svos-retheme` HAS NO HOLD AND WILL SWEEP.** Withdrawing the ask
+- ✅ **`booth-svos-retheme` IS KEPT** — design-dev ran `booth keep` after we
-  removed the last open pick and there is no `.forever`. Round 1's renders are
+  flagged that withdrawing his ask had removed the last hold. Round 1's renders
-  the only rendered baseline to judge round 2 against; they are reproducible
+  stay one click away while the operator chooses; he releases it once `flow` is
-  from the staged branch but not one click away. Flagged to him; `booth keep`
+  ruled.
-  is his call, not ours.
 - ✅ **ORDERING REVIEW DONE FOR ROUND 2's SURFACES** (he asked before building).
   His **ordinals rule improves invariant 6** — an ordinal that counts across ALL
   items makes "#07" stable under every filter, where today "the third one" is
-  ambiguous the moment a filter is on. Two corrections returned: flag "set
+  ambiguous the moment a filter is on.
-  order" IS `(created, id)` because `set_flag` upserts and unflag REMOVES, so no
+
-  new field is needed but the tie-break is; and "last activity" must reuse
+  ⚠ **One correction we sent was WRONG, and the record is corrected here rather
-  `_newest_mtime`, whose `.lock` exclusion is load-bearing — a naive `max(mtime)`
+  than left to be re-asserted.** We read his "SET order" as "the order they were
-  lets a no-op mark POST float a dead booth to the top.
+  set in" and told him it was already `(created, id)`. He meant **the SET's
+  order — by tile number.** Those genuinely differ: flag #15 then #07, and
+  today's panel lists #15, #07 while his tray lists #07, #15. His rule is also
+  cleaner than ours — the flag set sorted by its target's position in
+  `sorted(rel)` is a **total order needing no tie-break, because rels are
+  unique.** Do not re-raise the tie-break point; it was our misreading.
+
+  The correction that held: **"last activity" must reuse `_newest_mtime`**,
+  whose `.lock` exclusion is load-bearing — a naive `max(mtime)` lets a no-op
+  mark POST float a dead booth to the top. Taken, with no second definition of
+  activity on the Desk.
 - 🔶 **SVOS CONCEPT ROUND IS UP AND THREE RULINGS ARE WITH THE OPERATOR**
   (booth `booth-svos-retheme`, ask id `svos`: ship / voice / emblem, all three
   with design-dev's recommendation attached). **Nothing from us gates it and