docs: log the full-bleed hero work and what the hash check missed

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/history/DEVELOPMENT_LOG.md

@@ -32,6 +32,61 @@ written and stay true. It is exempt from review for the same reason a receipt is
 
 ## Entries
 
+### 2026-08-19 — Full-bleed onboarding heroes, and a hash check that proved the wrong thing
+
+The onboarding illustrations went from 11–17% of the screen to a third of it,
+full width, fading into the page. Three issues closed, one opened.
+
+**The artwork took two attempts and the first one looked right.** It arrived at
+the correct 2048 × 1365 and 3:2 — and was the old portrait art upscaled ~2.8×
+with the sides padded by a blurred copy of itself. The sharp region was
+1024 × 1365, aspect 0.750 against the originals' 0.748: the same composition.
+Measuring edge detail across each image found it falling 2.1×–8.8× in the outer
+quarters on 15 of 16 files, and at real hero size a hard seam showed around the
+sharp centre. The canvas was right and the composition was still portrait. The
+second delivery is natively wide.
+
+**A hash check proves two files differ, not that either is right.** `Dark/01`
+and `Dark/07` were byte-identical, which I recorded as "the forecast's dark
+illustration is a copy of the welcome one". Backwards: **both were forecast
+scenes.** Replacing 07 fixed the duplicate hash, the set passed a uniqueness
+check, and dark mode still opens on a calendar where light mode opens on
+overlapping rings. Filed as #44 — found by looking at the screen after wiring it
+up, which no checksum was ever going to do.
+
+**The cap is the part worth keeping.** A landscape phone is 914 × 411 dp, so a
+fixed 280 dp hero is 68% of the screen and every step breaks on rotation —
+nothing here uses `WindowSizeClass` and onboarding does not lock orientation.
+`Illustration` caps at a third of the screen, and it reads
+`LocalConfiguration.screenHeightDp` rather than `BoxWithConstraints`, because
+inside a `verticalScroll` column a child is measured with an **infinite** height
+constraint. `maxHeight` there is `Dp.Infinity`, so the obvious implementation is
+a guard that looks right and never applies.
+
+**Compose has no negative padding**, so the screen's 24 dp inset moved off the
+scrolling column and onto the content inside each step. That is what lets a
+full-bleed child exist at all.
+
+**And a live memory defect went with it.** The illustrations sat in a
+density-less `drawable/`, treated as mdpi and pre-scaled at decode — about 17 MB
+of heap for one bitmap on an xxxhdpi device, before this artwork made them
+larger. Four buckets per theme now. 2.3 MB across all of them, but a release is
+an AAB and Play splits by density, so a device downloads 130–500 KB.
+
+Seven hand-rolled step layouts became one `StepBody`, keeping `artHeight` per
+step: the two carrying three or four controls take a shorter hero, which is the
+constraint the old 104 dp values existed for.
+
+- **Closed:** #39, #40, #41.
+- **Next action:** #44 needs one re-render — dark `01_Welcome` as overlapping
+  rings to match its light twin. Then Batch 06's remainder: #37 is smallest and
+  unblocked, #35 export next, #34 app lock still waiting on the forgotten-PIN
+  decision.
+- **Blockers:** #9, the Command Center webhook, still needs a person. TalkBack
+  has still never been run and no real lock screen has been looked at. #42 would
+  have caught a missing night asset but not this one — a pairing guard checks
+  presence, not subject.
+
 ### 2026-08-18 — The wordmark got its space, and #28 closed
 
 The owner supplied a redrawn lockup, `docs/design/dist/splash.webp`. It sets the