re: refute the OB entity-flag on the FULL enumeration -- the stationary-entity hole is closed

Every earlier refutation in this file carried the caveat that entities2.typed
types entities by their position CHANGING, so a stationary objective is invisible
to it.  This session's definition-pointer enumeration does not have that limit, so
the sweep was re-run against it (ob_flag_all.py, guarded route, stage asserted,
HUD cropped beside each sample):

  A: HUD 004, 147 entities -> 152 candidates
  B: HUD 012, 133 entities ->  15 candidates
  intersection: 1

The lone survivor pos+0x0250 = 239d6732 is the same offset AND identical value
this file already characterised as a per-group word.  Membership test: all 12
holders are UN_e010_ADAN_Attacker_S, 12 of 16 live attackers.  It is a squad
parameter, and it survived only because that population equalled the counter at
both samples.

Also reconfirms "not a class head-count" on 147 entities including capital ships.

Trap recorded: the first sweep reported 298 entities and a class with head-count
exactly 4 -- a perfect-looking hit that was pure artifact.  Deduping by ADDRESS
leaves the measured exact 2x duplication (pairs 0x1000 apart, byte-identical
positions) intact and doubles every population.  Dedup on the position VALUE.

docs/re/mission-freeze-and-ob-flag.md

@@ -309,3 +309,63 @@ filter used, but the confirming screenshot at that instant did not agree.
 **What is still not ruled out** is unchanged from the word-level pass: anything
 outside the window, and anything on entities `entities2.typed` cannot see (it
 types by position *changing*, so stationary objectives are invisible).
+
+---
+
+## 🔴 2026-08-27 — the last hole is closed: refuted on the FULL entity enumeration too
+
+Every refutation above carried the same caveat: *"anything on entities
+`entities2.typed` cannot see — it types by position **changing**, so a stationary
+objective is invisible to it."* That hole is now closed, because this session
+established an enumeration that does not have it — search for the **definition
+pointer** and take `position = hit - 0x130`
+([`two-entity-enumerations.md`](two-entity-enumerations.md)), which finds every
+entity moving or not, capital ships and the `ACROPOLIS` included.
+
+Re-run with that enumeration ([`ob_flag_all.py`](../../tools/re-capture/ob_flag_all.py)),
+guarded route, stage asserted, HUD cropped beside every sample:
+
+| pass | HUD | entities | candidates |
+|---|---|---|---|
+| A | `004` | **147** | 152 |
+| B | `012` | 133 | 15 |
+| **intersection** | | | **1** |
+
+The lone survivor is **`pos+0x0250 = 239d6732`** — and it is **the same offset and
+the identical value** this file already characterised as a per-group word. Put to
+the membership test rather than admired:
+
+```
+holders of pos+0x250 == 239d6732 : 12
+    12  UN_e010_ADAN_Attacker_S      (of 16 live attackers)
+```
+
+**All twelve are attackers.** It is a squad parameter or pointer shared by part of
+the `e010` population, and it survived only because that population happened to
+equal the counter at both samples. Not an objective flag.
+
+### What this adds
+
+* 🔴 The **"objectives are marked in the entity object"** family is now refuted on
+  an enumeration that **includes stationary entities** — the limit every earlier
+  pass had to state is gone, not merely narrowed.
+* 🔴 **"Not a class head-count" is reconfirmed on 147 entities including capital
+  ships**: no class had a population of 4 at A or 12 at B.
+* ⚠️ **A trap worth having.** The first run of this sweep reported **298**
+  entities and a class with head-count exactly 4 (`UN_f105_TCAF_Cruiser`) — an
+  apparently perfect hit. It was an artifact: deduplicating by *address* leaves
+  this session's measured **exact 2× duplication** (pairs `0x1000` apart holding
+  byte-identical positions) intact, so every entity is counted twice and every
+  population doubles. Deduplicating by **position value** gives 147 and the
+  spurious class hit disappears. Any sweep of this shape must dedup on the
+  position triple, not the address.
+
+### Still open
+
+* ❔ Anything **outside** the `-0x400 … +0xC00` window — unchanged.
+* ❔ Sample A's holder membership was not re-checked (the world had moved on), so
+  "4 attackers at A" is inferred from B's membership plus this file's earlier
+  identification of the same word, not measured.
+* ❔ What the counter *does* count. Still unexplained: it read `004` with ~118
+  hostiles live, rose `004 → 012` as waves spawned, held through a third of the
+  hostile population dying, and decremented once when the player killed.