Prove the Firestore wire against a real phone and a second machine

#46 is merged. Everything in it is proven against a fake Firestore and nothing has run against a browser, a phone, or a second machine. This is the same shape as #52 was for #45: the code is done, and what is left needs hardware.

## Why it is a separate issue

#46's acceptance list had a set of items that cannot be checked from inside a sandbox — no browser, no phone, no second laptop. Leaving the ticket open indefinitely would have hidden the fact that the code half is finished and reviewed. So they move here.

## What has never happened

- Nobody has ever signed in to the cockpit from a phone.
- No command document has ever been written by a real browser or executed by the daemon against the live project.
- No mirror has ever been written to or read from the real `bench-cockpit` Firestore.
- No second machine has ever registered, so the merged roster has only ever been tested with one.
- No report has ever been rendered through `srcdoc` over the relay.

## Acceptance criteria

Do these by hand against the live project and say which ones you actually did.

- [ ] Broadcast a specialist on the laptop. Open the hosted cockpit on a phone **with wifi off**, signed into the same Google account. The specialist appears.
- [ ] Specialists that were **not** broadcast do not appear, and nothing about them exists in the Firestore console.
- [ ] Send it a prompt from the phone and get a turn back.
- [ ] Answer a decision from the phone; the answer reaches the live session.
- [ ] Open a report from the phone. It renders, in the right theme, in its sandboxed frame.
- [ ] Watch a live turn from the phone. The trail and plan move, and the Firestore console shows no command traffic for the plan — it should arrive on the mirror.
- [ ] Lock the phone for five minutes, unlock, and confirm the cockpit recovers rather than hanging.
- [ ] Turn broadcast off. The mirror documents disappear from the console.
- [ ] Leave the machine broadcast with no viewer for five minutes and confirm from the console that reads slow down rather than stop.
- [ ] With nothing broadcast, confirm no read traffic at all.
- [ ] `bench remote off` empties this machine's subtree.
- [ ] **Two machines.** A second laptop signed into the same account appears in one merged roster, each row labelled, and a prompt sent to a row reaches the right daemon. This is the requirement that started the multi-machine design and it has never been tested with two real machines.

## Watch the quota while doing this

The free plan is 50,000 reads / 20,000 writes / 20,000 deletes a day, resetting around midnight Pacific, with no overage. Check the usage panel in the Firebase console before and after a session and record the real numbers — the cost model in the design is arithmetic, and this is the first chance to find out whether it matches.

## Out of scope

- #47, the mobile layout. Things will be ugly on a phone; note them there, do not fix them here.
- #48 encryption, #49 push notifications.
- #50 and #54, the test failures.

## Related

- #46 — the code, merged.
- #45 / #52 — the identity slice and its live-verification issue, same pattern.
- Blocks #47 in practice: no point styling a cockpit whose transport has not been proven.

Start with the hosted cockpit, the live Firestore project in the Firebase console, and the `bench remote off` entry point. Run the phone, browser, and two-machine acceptance checklist, including the `srcdoc` report and quota checks. Done means recording which criteria passed and the observed Firebase read, write, and delete totals.

Written by the indexing model from the issue text.