re: the 12288 region is a padded metadata block, and the assignment rule is 100%

Dumped it. In all 282 exceptions the region from the earlier wave's seek to the
first RIFF is exactly 12288 bytes: the seek chunk (240-260 bytes), then 47-57
non-zero trailer bytes, then zero padding out to the block size.

So an entry may hold a leading wave, a 12288-byte padded block, then its RIFF
wave -- and the assignment rule completes: first-or-second wave at/after the
entry offset is 7620/7620 = 100.00%, with ZERO unexplained.

This overturns my own refutation from one iteration ago. I proposed these were
leading segments, tested it as 'the seek should sit AT the first RIFF', got 0 of
282, and recorded the hypothesis refuted. It was right; my predicate was wrong
by exactly the padded block, a constant I had not yet found. A negative result is
only as good as the predicate it tests.

Still unidentified: what the 47-57 trailer bytes hold.

docs/re/structures/slb-data-offset.md

@@ -532,14 +532,37 @@ I first guessed these were leading segments, which would put the earlier wave's
 `seek` **at** the first `RIFF`. That is refuted: it happens **0** times out of
 282. Whatever occupies those 12 288 bytes is something else.
 
-❔ **Not settled**: what the 12 288-byte region is, and therefore whether the
-rule should be "first wave at or after the offset" (96.30 %) or that rule with a
-12 288 correction (which would reach 100 % on this set but is curve-fitting
-until the region is identified). **First step**: dump those 12 288 bytes for
-several of the 282 and see whether they are a second `RIFF` block, a padded seek
-table, or audio.
+### ✅ The 12 288-byte region is a padded metadata block — and the rule is 100 %
 
-⚠️ Consequence for the open duration question: this does **not** yet unblock
-headerless bank durations. The rule is 96.30 % on entries whose answer is
-checkable; on headerless entries there is nothing to check it against, so
-applying it there would be assuming the very thing that needs proof.
+I dumped it, as the previous paragraph said to. Across **all 282**:
+
+* the region from the earlier wave's `seek` to the first `RIFF` is **exactly
+  12 288 bytes — the same in every one**;
+* it opens with that wave's `seek` chunk (240–260 bytes);
+* the tail after the chunk carries **47–57 non-zero bytes** (median 52) and is
+  otherwise **zero padding**, filling the block out to 12 288.
+
+So an entry may hold a **leading wave, then a 12 288-byte padded block, then its
+`RIFF` wave**. With that, the assignment rule completes:
+
+| | |
+|---|---|
+| the entry's wave is the **first** wave at/after its offset | 7 338 (96.30 %) |
+| the **second** — a leading wave + 12 288 block precedes it | **282** |
+| neither | **0** |
+| **first-or-second** | **7 620 / 7 620 = 100.00 %** |
+
+**❌ And this overturns my own refutation from one iteration ago.** I proposed
+the earlier waves were leading segments, tested it as "the earlier wave's `seek`
+should sit **at** the first `RIFF`", got **0 of 282**, and recorded the
+hypothesis as refuted. The hypothesis was **right**; my test was wrong by
+exactly the padded block — the `seek` sits at `RIFF − 12 288`, not at `RIFF`. A
+negative result is only as good as the predicate it tests, and mine was too
+strict by a constant I had not yet discovered.
+
+⚠️ Consequence for the open duration question: the rule is now **exceptionless on
+the checkable set**, which is much stronger than the 96.30 % it replaced. It
+still cannot be *verified* on headerless entries — there is no `RIFF` there to
+check against — but "100 % wherever it can be checked, with a named structural
+reason for every case" is a materially better basis than before. ❔ What the
+47–57 non-zero trailer bytes hold is unidentified.