What's New: build the changelog lazily, as iOS already does

[ryanbr]

Finishes a fix the project already made on iOS.

What was wrong

WhatsNewSheet used Column + verticalScroll, which composes every release card up front on each open. There are 267 entries, each a surface plus a version/date row plus one row per bullet — on the order of a thousand text nodes measured in the frame the sheet appears. And one more release every time we ship.

Not a new idea

The Swift twin already does this and left the reasoning in the file:

"PERF: the changelog grows with every release, so this is an ever-lengthening column. LazyVStack … builds the off-screen release cards on demand instead of constructing the entire history up-front each time the sheet opens."

Someone judged it worth fixing on the platform where they could watch it happen, and the Android half was missed. This is that half.

Swept for the same shape before fixing the one instance

Other verticalScroll + forEach screens iterate bounded collections — settings rows, wizard steps, a day's tiles. The only other list that grows without bound is WorkoutsScreen, and it was already solved by pagination in #797 ("This card lives inside ONE LazyColumn item"). So the project has now handled this pattern in all three places it occurs.

The detail that is easy to get wrong

contentPadding, not Modifier.padding. The old padding was applied after verticalScroll, so it scrolled with the content. contentPadding preserves that exactly; a padding modifier would inset the viewport instead and change where content clips at the edges.

Arrangement.spacedBy(Metrics.sectionGap) carries over unchanged, so spacing is untouched.

Parity

iOS needs nothing — WhatsNewView already uses LazyVStack. This PR brings Android level with it rather than introducing a divergence.

No stored value or analytic changes, so the byte-identical contract is not involved.

Verification

• Kotlin: full src/main/java compile against a main worktree — 2517 errors both sides, 5 in this file both sides, error sets byte-identical. No new errors.
• Tools/doc_comment_lint.py clean; Tools/i18n_audit.py --ci clean.
• Both removed imports (rememberScrollState, verticalScroll) had no other use in the file.

What I did not do

Measure it. There is no Compose runtime here, so the magnitude is a structural estimate — ~267 cards composed eagerly versus ~4 visible plus prefetch — not a number. It would be worth a frame-time look on a mid-range device if anyone has one to hand, but the direction is not in question and iOS already committed to it.

The change is visually identical: header, hairlines, footer, card styling and the "newest is the headline" rule are all untouched. Only construction becomes on demand.

Re-review: the item keys were a crash waiting to happen

My first version keyed the items by release.version. LazyColumn throws IllegalArgumentException on a duplicate key, where the forEachIndexed it replaces rendered duplicates without complaint — so that would have handed a generated file the power to crash the What's New screen at runtime.

All 266 entries are unique today; I checked. But appchangelog-gen.py only guards the newest entry against duplication, so a re-released version or a hand-edit is all it would take, and the failure would land on a user-facing screen rather than in CI.

Keys are now dropped entirely. They exist so recomposition can track identity when a list inserts, removes or reorders — AppChangelog.releases is a compile-time constant that cannot change during a session, so there was no identity to track and the key was pure cost.

Worth naming the bad reasoning that put it there: I copied the Swift ForEach(… id: \.element.id) as though it were evidence that a key was wanted. It is not — SwiftUI's ForEach requires an identifier, LazyColumn does not. Mirroring a twin is only a good argument when the constraint is the same on both sides.