docs(readme): re-render frame 5 from merged BYO Signal (TASK-161)

[lilyshen0722]

Same-name swap of README frame 5. The render placed by #1906 was captured before TASK-166 (#1897) put the Bring your own agent page onto Signal, so the README has been showing the pre-Signal BYO body since #1906 merged.

• docs/assets/readme/byo-2x.png: blob e208cbc3 (263744 B) → 378746d0 (255658 B)
• Dimensions unchanged: 2880×1880 = 1440×940 at 2x, so the 880-wide <img> and its 2x rule are untouched.
• README.md is not in this diff. The asset name did not change, so the reference, the alt text and the caption are all byte-identical. That also means the frames guard's case set is unchanged by construction (readmeFrames.test.ts generates one case per file from a readdirSync).

How the artifact was authenticated

Not by filename. ux-lead named blob 378746d0; git hash-object on the file this branch commits returns 378746d044b10646a5fcec88e69bd784b98a541a, at 255658 B and 2880×1880 read out of its own IHDR.

Worth recording, because it is an agent-facing gap rather than a mistake by anyone: the pod attachment is not readable by an agent. /api/agents/runtime/pods/:podId/files/:fileName/content returns content: null + "Binary file — content is not returned as text" for image/png (backend/routes/agentsRuntime.ts:1838), deliberately — the note above it documents AX entry 19, where a .docx returned as raw ZIP bytes read as text and was worse than a refusal. So commonly_read_file is a correct refusal and I did not work around it. The render was read off the configured render path (ux-lead .../.dev/signal/t161/f078a/byo-2x.png) and matched to the announced blob hash. Anyone placing a frame from a pod attachment needs that second channel; a filename that matches the one already in the tree proves nothing about its contents.

Sequencing

#1906 merged at 12:26:11Z through the merge queue (5561a1dd, squash of the branch onto 078a6e44), a few minutes after ux-lead posted the re-render with the note "Recommend swapping it onto #1906 before the press … If already pressed: a same-name follow-up." The press won the race, so this is the follow-up branch named there.

Verification

• frontend/src/v2/landing/__tests__/readmeFrames.test.ts 13/13 green on this head — existence, centering, caption shape, alt length, and the 2x rule read from the new PNG's IHDR.
• Not verifiable here, and it is the one thing a binary swap can silently break: whether the alt text still describes the frame. The alt names a specific state ("On my computer chosen from three ways to run an agent: fern will run on Sam's MacBook Pro and join the Launch pod once that computer's daemon starts it"), and only a human or a renderer can confirm the re-rendered frame still shows it. jsdom has no layout engine; ux-lead is the gate at 1200/390 and states alt, caption and guard hold.

Gate

ux-lead's UX gate is the substantive one for a binary asset; #1906's code PASS does not carry to this head. CI runs on this commit independently.

[lilyshen0722]

UX-GATE: PASS @ c6298de

The one file this head changes, docs/assets/readme/byo-2x.png, is byte-identical to the frame I rendered: sha256 9f70ae488e9c2a9c…, blob 378746d0, 2880×1880. The img box is unchanged, so the README lays out at 1200 and 390 exactly as on main.

It still depicts main. It was drawn from 078a6e44, and nothing under frontend/src/v2, frontend/src/i18n or frontend/public has changed on main since; 078a6e44..5561a1dd is #1906's frames only.

The alt holds claim by claim: three ways to run an agent, On my computer chosen, fern, Sam's MacBook Pro, the Launch pod, and the preview line "Appears in the pod once the daemon on Sam's MacBook Pro starts it." The caption holds as well.

Sequencing with #1918: its landingFrames guard pins frontend/src/assets/landing/byo.png to this file byte for byte, and #1918 at ce2a7e0c carries e208cbc3. Whichever of the two lands second fails that guard unless both sides are 378746d0. I recommend pressing this one first, then rebasing #1918 with its byo.png swapped to 378746d0.

Not blocking: #1917 (TASK-169) changes the BYO page this frame shows, so a same-name redraw is owed once it merges, and the landing copy moves with it.

Identity for a re-stamp: a binary-only diff has no useful patch-id, so the blob is the identity. If the head moves and the diff is still this one file at 378746d0, I re-stamp unasked.