docs/re: the ship test's one-way gap was already half closed, and is now shut

Records both halves rather than just the fix: the "extra static placements
cannot fail it" line had been stale since `a21aa5f`, and the residual — a set of
names being blind to a duplicated instance — is what this round actually closed.

Also states what it does not close: the multiset is `e106`'s alone, so the
per-ship table this entry originally asked for still needs a runtime capture of
a second capital ship, i.e. the `capture-ship-placement` build of Canary.

docs/re/BACKLOG.md

@@ -396,3 +396,34 @@ each resource near its **descriptor neighbours** (two-pass: learn, then re-ancho
 
 Still open from this entry: `static_assembly_matches_runtime_capture` walks only
 the capture's parts, so **extra** static placements still cannot fail it.
+
+### 2026-08-18 — that last line was stale, and the residual gap is now closed too
+
+**The one-way-test complaint had already been fixed** when this entry was
+written down: `64d372c` (the revert commit itself) added an extras check, so
+"extra static placements cannot fail it" has not been true since. Checked rather
+than assumed — perturbing the expectation makes the test fail with the real disc
+behind it, so it runs and is live, not a `SYLPHEED_ISO`-less skip.
+
+**But it compared a set of resource *names*, which leaves one direction open**: a
+resource placed *twice* when the capture lists it once changes no set. That is
+not hypothetical — a duplicated instance is exactly what a bad node walk emits,
+and the two legitimate duplicates here (`e106_eng_01`, `e303_wep_01`) are the
+reason the test had to special-case counts at all. Replaced with the full
+**multiset**, pinned to the e106 ground truth:
+
+```
+e106_bdy_01 1  e106_bdy_02 1  e106_bdy_03 1  e106_bdy_04 1  e106_brg_01 1
+e106_eng_01 2  e106_eng_02 1  e106_wep_02_01 1  e303_wep_01 2
+```
+
+— 9 resources, 11 placements, against the capture's 8 dedup'd parts. That
+subsumes the two hand-written count assertions, and it now fails on an extra
+resource, a missing one, **and** a duplicated one. Refuted before believing:
+declaring `e106_bdy_01` twice makes it fail, with the real multiset on the left.
+
+**Not closed by this**, and worth keeping separate: the multiset is `e106`'s
+alone. The generalisation this entry originally asked for — a per-ship table so
+a regression in one class cannot hide behind `e106` passing — still needs a
+runtime capture of a *second* capital ship, which needs the
+`capture-ship-placement` build of Canary.