Take the project's own story out of the README, starting with a claim about elapsed time

USER CORRECTION: the README is a description, not a chronicle, and the intro
had it narrating an arc -- "for most of this project's life that was read as a
video codec problem" -- which is also a claim about elapsed time that nothing
measured supports. The tree is days old.

The intro now states the design: it is a delivery problem, the live design has
no decoder in it, and the comparison that settles it is a measurement (37,585
decoded costs more than 49,152 not decoded; 110.4% against 54.9% at the 9 clk/B
floor). The codec is "in the tree and parked (USER DECISION)" -- no session
number attached, because which sitting it happened in is STATUS's business.

Four more of the same, found by grepping rather than by eye:
  - B2 "is not a headroom question any more" -> it decides which player exists
    rather than how much headroom one has.
  - "Other things the machine has said" -> "What else a player has to carry".
  - ring.i/xfer.i/stream.s "left the video path when a DMAC-direct player
    deleted the ring" -> a DMAC-direct player has no use for them, because it
    has no ring. Same edit in the parked list and in Layout.
  - "Why it is parked" kept the standing reason and dropped the retelling.

And one where the story was carrying a fact that had to stay: the sasi profile
was "dropped on capacity rather than bandwidth" with the numbers left in
FINDINGS. They are in the sentence now -- a 40 MB volume against 146 MiB of
game -- so the clause survives without the reader needing the episode.

One "session" reference stays, at the STATUS.md bullet: that file IS ordered
newest session first, and saying so is navigation for another document rather
than this one telling a story.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

README.md

@@ -3,15 +3,18 @@
 Porting Dragon's Lair to a stock X68000 (68000 @ 10MHz, 2MB, SCSI).
 
 The game logic is a scene table with branching input windows. The difficulty is
-pushing ~22 minutes of Don Bluth animation through a 10MHz 68000, and for most
-of this project's life that was read as **a video codec problem**. It is not.
-Measured on the machine, the codec costs more to *decode* than a literal frame
-costs to *not decode*, so the live design has **no decoder in it at all**: the
-disc holds packed 8-bit frames and a DMA channel walks them into GVRAM with the
-CPU halted. It is a **delivery** problem — bus cycles and bytes off a disc.
+pushing ~22 minutes of Don Bluth animation through a 10MHz 68000, and it is a
+**delivery** problem rather than a compression one — bus cycles and bytes off a
+disc.
 
-The codec still exists, still works and is **parked** (USER DECISION, session
-29). Both branches are described below; the packed one is where the work goes.
+**The live design has no decoder in it.** The disc holds packed 8-bit frames and
+a DMA channel walks them into GVRAM with the CPU halted. Measured on the machine,
+decoding 37,585 bytes costs more than not decoding 49,152: at the 9 clk/B
+dual-address floor the codec is 110.4% of a 12 fps frame and the decoder-free
+packed player is 54.9%.
+
+A working codec is in the tree and is **parked** (USER DECISION). Both branches
+are described below; the packed one is where the work goes.
 
 ## What it looks like
 
@@ -143,11 +146,11 @@ difference between them is *when* the window is open:
 
 B's paint is **measured**: the packed `movem` blit is 227,553 clocks, 27.3% of a
 slot, independent of the medium. They are equally visible only at **3.7x the
-wire**. So B2 — *does buffer mode blank the display?* — is not a headroom
-question any more; it decides which player exists, and **K4 is not being built
-until it is answered** (FINDINGS 64.2, ROADMAP K4).
+wire**. So B2 — *does buffer mode blank the display?* — decides which player
+exists rather than how much headroom one has, and **K4 is not built until it is
+answered** (FINDINGS 64.2, ROADMAP K4).
 
-### Other things the machine has said, that a player has to carry
+### What else a player has to carry
 
 **A held channel costs the frame clock half its ticks, without the clock being
 able to tell.** `clock.i` counts V-DISP interrupts; a held channel halts the
@@ -221,13 +224,12 @@ than trimming it. [`docs/img/modes.webm`](docs/img/modes.webm) is the same windo
 with the block-mode map beside it — black SKIP, blue V1, amber V4, red RAW —
 which is what every cost table in FINDINGS is really about.
 
-**Why it is parked.** At the 9 clk/B dual-address floor the codec is **110.4% of a
-12 fps frame and the decoder-free packed player is 54.9%**: decoding 37,585 bytes
-costs more than not decoding 49,152. Reaching a fitting rate needs a 35% byte
-reduction after two of its three levers were measured and found inert, and the
-reward on success is a design at ~100% of the frame. **It is kept on disk and not
-built on** — if B2 comes back "buffer mode blanks", it is the only thing left
-(FINDINGS 61.8, 48.3).
+**Why it is parked.** Its remaining path is a conjunction and the packed one is
+not: reaching a fitting rate needs a 35% byte reduction, two of its three levers
+measure inert, and the reward on success is a design at ~100% of the frame
+against the packed player's 54.9%. **It is kept on disk and not built on** — if
+B2 comes back "buffer mode blanks", it is the only thing left (FINDINGS 61.8,
+48.3).
 
 ## What is open
 
@@ -266,8 +268,8 @@ emulator.**
    is B1's.
 
 **Parked, so it is not re-proposed:** the codec's remaining encoder work (E7, E4,
-C1); `ring.i`, `xfer.i` and most of `stream.s`, which left the video path when a
-DMAC-direct player deleted the ring, and P4a's wiring with them. **K4 is blocked
+C1); `ring.i`, `xfer.i` and most of `stream.s`, which a DMAC-direct player has no
+use for because it has no ring, and P4a's wiring with them. **K4 is blocked
 on B2**, not parked.
 
 ## Reproducing this
@@ -374,7 +376,8 @@ python3 tools/encoder/encode.py tmp/fr_singe out.dlx --profile scsi --preview p.
 `--kbps` is the quality rate point and `--span-kbps` the ceiling the span pass may
 draw on; `mu` is bisected per frame against the 68000's own decode budget so a
 frame also *decodes* in time. One profile, `scsi`; the 110 KB/s `sasi` profile was
-dropped on capacity rather than bandwidth. The RAW escape means `lam=0` is
+dropped on capacity rather than bandwidth — a SASI volume is 40 MB and the
+game is 146 MiB even at that rate. The RAW escape means `lam=0` is
 pixel-exact against the palettised frame. See FINDINGS 31/41/44 before changing
 any of it.
 
@@ -416,7 +419,7 @@ src/player/      packed.s    THE LIVE PLAYER: display bring-up, the 193-entry DM
                  stream.s    asserted), the same decoder behind a bounded ring,
                  ring.i      the ring producer, the transport under it, and the
                  xfer.i      load-time codebook/palette transforms. OUT OF THE
-                 load.i      VIDEO PATH since the packed player deleted the ring.
+                 load.i      VIDEO PATH: a DMAC-direct player has no ring.
                  frame.i     the block loop and span chain, included by both, so
                              there is exactly ONE copy of the bytes every cycle
                              constant is fitted to. The span pass is blit.s v7