Hand a tablet to open house visitors: a full-screen sign-in page where each visitor types their name and email, sees a thank-you, and never sees who signed in before them #125

Intent: today the agent types each open house visitor into the follow-up email page by hand, from the printed sign-in sheet. In the meeting, the agent should be able to hand a tablet to visitors at the door and get the follow-up list filled in for them.

Done looks like:

• GET /listings/:id/open-house renders a large, touch-friendly, server-rendered page in the agent's brand and palette. It shows the address and hero photo, name and email fields, and one big "Sign in" button. It shows no tool header, no other visitors and no links into the rest of the app. Reuse the public face of Frame in src/pages/layout.ts.
• Only the listing's agent or an admin may open the page, asked through permit / the same check addVisitor uses. Anyone else gets the same refusal as the visitors list. The tablet runs on the agent's own signed-in session. No contract cell changes: no anonymous create.
• Submitting is a same-origin POST that calls the existing addVisitor (name and email validated as they are today). It redirects back to the same page with a short "Thanks for stopping by, <first name>" that clears after a few seconds or on the next tap. The page never echoes an earlier visitor's name or email after that.
• An invalid email shows the error in place and keeps the typed name. A listing with no open house still works (an agent may hold a private showing).
• The listing page and the printed sign-in sheet link to it as "Sign-in screen for a tablet". The README walkthrough names it on the 412 Alder Lane sample.
• Tests: the agent gets 200. A guest and another user are refused. A POST adds a visitor that the open house follow-up email then lists. The thank-you page contains no earlier visitor's email. The page answers within the existing speed test's budget.

Files likely: a new src/pages/openhouse.ts, src/routes.ts, src/pages/listing.ts (link), the sign-in sheet page, src/openhouse.test.ts, README.md. Run bun scripts/design-lint.ts for any new classes, and name them in docs/design/areas/<area>.md.

Risks: the session stays signed in on a shared tablet, so the page must not lead anywhere else. Its only way out is a small "Done" link back to the listing. Escape every echoed name.

Suggested crew: builder.

Reviewed pull #127 at its head: ticked GET /listings/:id/open-house renders a large, touch-friendly, server-rendered page in the agent's brand and palette. It shows the address and hero photo, name and email fields, and one big "Sign in" button. It shows no tool header, no other visitors and no links into the rest of the app. Reuse the public face of Frame in src/pages/layout.ts.; Only the listing's agent or an admin may open the page, asked through permit / the same check addVisitor uses. Anyone else gets the same refusal as the visitors list. The tablet runs on the agent's own signed-in session. No contract cell changes: no anonymous create.; Submitting is a same-origin POST that calls the existing addVisitor (name and email validated as they are today). It redirects back to the same page with a short "Thanks for stopping by, <first name>" that clears after a few seconds or on the next tap. The page never echoes an earlier visitor's name or email after that.; An invalid email shows the error in place and keeps the typed name. A listing with no open house still works (an agent may hold a private showing).; The listing page and the printed sign-in sheet link to it as "Sign-in screen for a tablet". The README walkthrough names it on the 412 Alder Lane sample.; Tests: the agent gets 200. A guest and another user are refused. A POST adds a visitor that the open house follow-up email then lists. The thank-you page contains no earlier visitor's email. The page answers within the existing speed test's budget..