android: turned over, for real — the walk rotates the phone, and puts it back Round twenty-seven wrote the landscape layout and proved it at 915×411 in headless Chrome; no real device had ever been turned, and the phone walk refuses a `{ view: [...] }` step because a device's orientation is not the step list's to set. That refusal stays. The turn goes in the phone tail instead, right after `background` has proved playback is live with the app off screen, and it asserts the four things the mock physically cannot show: `screen.orientation.angle` is 90 or 270 — an override without `screenOrientation` leaves the angle at 0, so this one is only ever a real phone — the WebView RESIZED as well (a separate clause, because a WebView that never got the configuration change looks exactly like a display that never rotated), `--nav-h` computed to 48px so the phone-sized landscape query really fired, and the activity was not recreated: the same window token, the same `performance.timeOrigin`, the same pid, no `AndroidRuntime` fatal — and those last two are read tolerantly, because `pidof` exits 1 when the process is GONE and `adb()` throws on a non-zero exit, so the plain read threw the whole report away at exactly the moment it mattered. Then the stack, the track still playing and past where it was (a track that rolled over during the turn is still playing, which is all the clause claims), nothing clipped, and the player sheet sideways in two columns with every control on screen. The safe-area insets are printed, not asserted. Nobody had ever measured them here — `MainActivity` calls androidx's `enableEdgeToEdge()` and nothing in the generated Kotlin touches insets, so `env()` comes straight out of Chromium's window-inset mapping — and asserting a number nobody has measured is how a round fails on a correct build. What is asserted is the plumbing, on both edges, because a hole-punch is only on one of them: whatever `env()` says, the glass bar, the mini bar, the screen and the sheet spend it. The phone is Kyle's, so the two rotation settings are read before either is written and put back from four places — the block's own finally, main's finally, `process.on("exit")` and SIGINT/SIGTERM/SIGBREAK — because a failed clause only walks on but a WebView that stops answering throws clean out of the loop, and Ctrl-C runs no exit handler at all. The latch clears itself before it writes, a failed restore hands it back for the next caller, and the skip paths disarm rather than restore, so a phone that could not be read, one already sideways and `--no-rotate` all leave it untouched. Nothing else on the device is written. One thing beyond the turn: the `{ adb }` step kept its stdout. `am start` prints "Error: Activity not started, unable to resolve Intent" on stdout and exits 0, so `share-import` — the step that exists to prove the share intent resolves — could not fail for its own reason. It can now.