1.9.1 — the default page is the server's answer

Anyone who is not the operator can now open the app.

Fixed

• The client fell back to page 1, which is the operator's page (#240). app.ts kept a
  DEFAULT_PAGE_ID = 1 and used it as the page to fall back to — a constant that #230
  made wrong without making it fail, because the default page is defaultPageFor(owner)
  and page 1 is only ever the operator's. For anybody else the fallback was a page they did
  not own: a 404, then a second 404 the code had no handler for, and a blank screen at /.
  Found on production by opening an invite link in a browser that already held a session.

  There is now no client-side constant for the default page. A request that names none
  asks the server, and the answer names the page it got — which the device then remembers,
  so the next boot asks for the right one directly.

• A browser spec that boots as a member (member.spec.ts), which no spec had ever
  done. That is the coverage gap the bug lived in: every other spec logs in as the
  operator, whose default genuinely is page 1, so all 244 of them agreed with it.
  Restoring the old fallback now fails that spec on the exact symptom — a blank screen.

• A test that snapshotted an asynchronous outcome (render.spec.ts). The dev mark on
  the icons and the tab title are swapped when /health answers, which is after the
  editor is on screen; reading them once passed on every quiet machine and failed twice on
  2026-08-30 — once in CI, once in the production gate, where it skipped a deploy. Retried
  now; the assertions are unchanged.

• The browser seed clears test members between runs. They accumulated in the local D1 and
  the people spec invites one per run, so MAX_USERS = 25 would have begun failing after
  about a dozen runs — as what looked like a broken cap.

Full changelog: v1.9.0...v1.9.1