docs: the fix closed a type confusion, not pointer-smuggling as a class

Both the LIMITATIONS bullet and the 1.1.0 CHANGELOG entry said "both now
FAIL_SECURE at T2, before the allowlist is reached" and stopped there. True,
and stronger than what shipped: the old bullet's closing clause about T3's
scope went out with the rewrite, so the text read as though a pointer can no
longer reach the consumer tree through frontmatter.

Measured, not reasoned:

  attester: attesters/sql_equality.py   -> WARN          (unchanged)
  resource: attesters/sql_equality.py   -> FAIL_SECURE   (unchanged)

T3 inspects `resource` and nothing else, so an honest string under another key
rides through exactly as before -- scanned under T1 like any other frontmatter
value, but never allowlisted. That is by design and is not what 1.1.0 changed.
Restored in both places.

Also corrects the row arithmetic: 13 added and 3 retired, not "11 added, 1
retired". Net +10 and 802 were measured and are right; the parenthetical was
not, and 2400 != 2401 is a locked convention here.

Tag v1.1.0 does not move: the code is correct, the prose about it was not.
802 passed, 35 limitations, :43 still the bullet's anchor line.

CHANGELOG.md

@@ -33,6 +33,12 @@ while closing it**, and is the reason this release names two routes rather than
 Neither shape is conformant OKF — a well-formed bundle does not produce them; a
 malformed or hostile one can.
 
+**What closed is the type confusion, not pointer-smuggling as a class.** T3 still
+inspects `resource` and nothing else, so an honest string under another key rides
+through exactly as before: `attester: attesters/sql_equality.py` is WARN, while
+the same path under `resource:` FAIL_SECUREs. The string is still scanned like any
+other frontmatter value under T1. Nothing about that changed here.
+
 **The boundary is where YAML puts it**, ground-truthed against PyYAML 6.0.3 rather
 than reasoned: `": "` and a trailing `":"` are exactly the two shapes where a plain
 scalar becomes a mapping, and they are refused. A colon carrying neither a space nor
@@ -46,8 +52,10 @@ here — the `1.0.0` entry says exactly this is a fix, not a break. A consumer w
 bundles carry an unquoted `": "` in a frontmatter value will now see those concepts
 refused at import; quote the value, and it parses.
 
-Suite 792 → **802** (11 rows added, 1 retired). 129/129 classes, 6/6 documented
-gaps, 35 limitations — all unchanged.
+Suite 792 → **802**: 13 rows added (4 rejected shapes, 7 admitted ones, 2 through
+`import_bundle`), 3 retired (the two that pinned the defect, and the one-key row
+in the block-list table). 129/129 classes, 6/6 documented gaps, 35 limitations —
+all unchanged.
 
 
 ## [1.0.0] — 2026-08-13

docs/LIMITATIONS.md

@@ -57,7 +57,13 @@ items; this is the full list, each with the mechanism.
   outright). Both parsed "successfully" into the wrong *type*, and a pointer parked
   in one rode through in a key the `resource` allowlist never inspects — mode-b
   `import_bundle` returned WARN and wrote the merged concept verbatim. Both now
-  FAIL_SECURE at T2, before the allowlist is reached. **The boundary is where YAML
+  FAIL_SECURE at T2, before the allowlist is reached. **What closed is the type
+  confusion, not pointer-smuggling as a class:** T3 still inspects `resource` and
+  nothing else, so an honest *string* under another key rides through exactly as
+  before — `attester: attesters/sql_equality.py` is WARN, while the same path
+  under `resource:` FAIL_SECUREs. That is by design (the string is scanned like
+  any other frontmatter value under T1) and it is not what `1.1.0` changed.
+  **The boundary is where YAML
   puts it**, ground-truthed against PyYAML 6.0.3: `": "` and a trailing `":"` open a
   mapping and are refused; a colon carrying neither a space nor a line end
   (`domain:security`, `https://e.com:8443/a`) does not and still parses, as does a