docs: C10.04 is blocked by the same exclusion that unblocked C5.15

CHANGELOG.md

@@ -11,6 +11,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- **`C10.04` attempted and withdrawn: it is blocked by the same exclusion that unblocked `C5.15`.**
+  A Mode 5 scene with `MOSAIC = $01` was written against the control the working rules require — the
+  same canvas with mosaic off — and hashed **identically to it on both references**
+  (`0xf7ed8ab9ecd95d85` either way).
+
+  The reason is structural. A 2x1 mosaic pair merges an *even* column with its *odd* neighbour, and
+  `HiResEven` samples only the even columns, so the merge is invisible to the hash **by
+  construction**. `C10.04` therefore sits with `C5.06`/`C5.07`: its subject lives in the mainscreen
+  half, which the references diverge on by 33-35% pairwise and which rule 4 forbids blessing. No
+  variant of `HiResEven` can help — any rule including the odd columns inherits the disagreement.
+
+  Recorded rather than silently dropped, because the *attempt* is the finding: this is the
+  unshowable-scene trap in its documented form, and **the control scene is the only thing that
+  distinguishes "the references agree" from "nothing happened"**. Its doc comment said in advance
+  what an equal hash would mean, which is why the trap cost one run instead of a blessed golden that
+  proved nothing.
+
 - **`C5.15` is now blessed coverage: excluding the one undefined pixel made the rest of Mode 5
   agree.** The retraction below establishes that the first hi-res pixel of a line is a genuine
   reference disagreement on a value ares flags as *not confirmed on hardware*. Hashing it would have

docs/adr/0013-accuracysnes-framebuffer-oracle.md

@@ -240,3 +240,28 @@ The method note is the durable part. Two references agreeing is not "the referen
 project counts ares and bsnes as **one** reference precisely because lineage matters, and here the
 lineage that disagreed was the one not consulted. Read the third source *before* publishing a defect
 claim, not after.
+
+### `C10.04` is blocked by the same exclusion that unblocked `C5.15`
+
+Attempted 2026-08-02 and **withdrawn**, because the attempt is worth more written down than the
+scene would have been.
+
+`C10.04` says a mosaic of **1** is the identity at 256 pixels but a **2x1 pair of half-pixels** in
+true hi-res. A Mode 5 scene with `MOSAIC = $01` was written against exactly the control the working
+rules ask for — the same canvas with mosaic off — and it hashed **identically to that control on
+both references**: `0xf7ed8ab9ecd95d85` either way.
+
+The reason is structural, not a bug in the scene. A 2x1 mosaic pair merges an *even* column with its
+*odd* neighbour, and `HiResEven` samples **only the even columns**. The merge is therefore invisible
+to the hash by construction: the extraction discards precisely the columns the assertion is about.
+
+So `C10.04` sits with `C5.06`/`C5.07` — its subject lives in the **mainscreen** half, which is the
+half the three references diverge on by 33-35% pairwise and which rule 4 therefore forbids blessing.
+`HiResEven` does not unblock it, and no variant of `HiResEven` can: any rule that includes the odd
+columns inherits the disagreement.
+
+This is the *unshowable scene* trap (`CLAUDE.md`) in its exact documented form — "a scene can arrange
+a state no picture can show; an unshowable scene hashes stably and every emulator agrees with it."
+The control scene is what caught it, and its doc comment said in advance what an equal hash would
+mean. **Write the control first; it is the only thing that distinguishes "the references agree" from
+"nothing happened".**