A preview shows production's data and never says whose it is #222

Walked on origin/main (exported and booted from a temp tree). Wrote a note into production through the app itself, then opened a change and read its preview with a grant of its own:

POST  http://zip.localhost:4031/api/notes      -> 201
GET   http://zip.localhost:4031/api/notes      -> [{"id":1,"body":"a note in production","author_name":"zoe",…}]
GET   http://zip--1.localhost:4031/api/notes   -> [{"id":1,"body":"a note in production","author_name":"zoe",…}]

Same note, same id, same author. The behaviour is correct — src/apps/data.ts says it plainly: a preview starts from a copy of production's data, taken when the preview is created, copy-on-write where the filesystem allows, with every SQLite file checkpointed first. That is a good design and nothing here asks to change it.

What is missing is the sentence. The studio never says it. The change page's Preview card reads Preview · Running · 535f113 · live 0.3s after the push · up just now · last deploy and the word data appears nowhere on the page. So a person opening their change's preview sees their production notes, their production users, their production everything — and has no way to know whether typing into it is safe, whether what they see is live production, or how old the copy is. The two honest answers ("this is not production" and "this copy is from when the change opened") are exactly the two a person needs before they press a button.

Done looks like

• [ ] A preview says whose data it has, in one line in the studio's voice, where the preview is offered: its own copy of production's, taken when the change opened.
• [ ] When the copy has an age worth knowing, it says when it was taken, the same way the rest of the page says up just now.
• [ ] Production's own card never gains the sentence — there is nothing to warn about there.
• [ ] One line, one place: the app page's previews list and the change page's Preview card take it from the same function, not two copies of a sentence.
• [ ] It costs no work on the render path — the fact comes from what the preview environment already knows, not from stat-ing a directory while drawing a page.
• [ ] Tests: a change's page names the preview's data as its own copy and gives the moment it was taken; production's card does not. They fail on today's code.

Files I expect to change

src/web/pages/apps.ts (previewCard), src/web/studio/previews.ts (the previews list), src/apps/data.ts or src/apps/runtime.ts if the moment the copy was taken is not already carried on EnvStatus, test/studio.test.ts.

Risks

The sentence must not become a warning banner — a preview with real data is the point of a preview, not a hazard. Keep it one quiet line beside the address. If the copy's timestamp is not already known, prefer the preview environment's creation time over touching the filesystem during a render.

Suggested: Quill.

Parked by the crew: the check failed and the decider saw no point in another try (pull #236 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the gate, not by the work. Pull #236 was written, complete and tested — \previewDataNote\ in \src/web/ui.ts\ as the one place the sentence is written, wired into both the change page's Preview card and the app page's previews row, with production's own card deliberately untouched, and a test that waits for a real preview deploy — and the check that failed it is red on main before any change is made. I measured that on an unmodified export of origin/main in a sandbox like the one the crew runs in: test/pulls.test.ts fails with git push origin main: remote: auth required, and studio + apps + web together give 209 pass, 4 fail — one more push-auth failure and three assertions, one of them #225's own test.

So this issue is not re-scoped: what done looks like above stands, and the branch from #236 is the starting point — read it before writing anything.

Two things are added to it:

• [ ] It waits on #233 (the check passing on main where the crew runs). Taking it before that means meeting the same wall a third time.
• [ ] Before pushing, run the repository's own check command. If something fails, the pull names the failing tests and proves they fail identically on the base commit — that evidence is what makes a red check reviewable instead of a park.