v0.27.0 - work-area navigation, a named estate, a reporting window, and a demo that boots signed-on

What this is

The portal's shell and pages, reworked around the jobs people do in it, plus the small receiver and demo changes that make it feel like a product from the first screen.

Portal

Shell and navigation

• Pages are grouped into work areas in the sidebar: Overview, Discovery, Governance, Operations, Settings. Areas stay open independently; pages can be pinned to the top, and the pins follow the account.
• The estate control beneath the logo names the organisation (a new central setting, see below), reports how many detection sources are reporting, and opens System health. The top-bar badge says "Monitoring active", "No sources reporting" or "Data unavailable" from the same read; none of it is fixed text.
• The search box filters the page where there is a list, and on every page it is a finder for pages, tools, devices, people and MCP servers. Enter opens the first match.
• The reporting window is a control: 24 hours to 90 days, on the Overview header and under Settings > Display & alerting, shown as a label on every other page. The choice is a preference of the account and is sent on every read that accepts one, so every page and both downloads agree. Every time label follows it.
• The account control at the top right holds change password and sign out, and survives phone widths.
• Light and dark palettes, typography and tables follow the reviewed design.

Pages

• Overview: a posture panel with the estate's metrics. "Monitoring healthy" needs at least one source to have reported in the window; a silent fleet says "Nothing reporting". Export PDF prints the page. The AI spend card lists its linked plans.
• AI register reworked as a decision workspace; Devices with a four-signal summary; Source coverage on one five-column schema; Budget wizard tightened; Evidence centre as an index of what the platform can show records for, with Export PDF beside Download JSON; System health as a dashboard whose count includes only the checks it runs.
• Printed pages carry a stamp naming the estate, the window and the time of export, and hide their own controls.
• The guided tour is rewritten for this navigation in plain wording, reaches every work area, has a stop on the Overview's Edit button, applies its account step only in login mode, and moves between steps without gliding or blinking. Its version is bumped, so everyone who saw the old tour is offered this one once.

Receiver

• org_name is a central setting. It is served unauthenticated by GET /admin/setup alongside the SSO flags, because the sign-in screen greets the organisation, and it is capped at a name's length.
• SETUP_CODE pins the first-boot setup code. It exists for the demo stack and the receiver prints a warning naming the risk on every boot it is set. Unset, nothing changes.

Demo

• The seeder walks the first-boot path itself: it claims the pinned setup code, creates the owner account (gengar, address gengar@example.com), names the estate "Pallet Town Ltd", switches single sign-on on against the stand-in provider, links three Budget plans with seat tiers and member lists, and enrolls three devices. The portal opens on a sign-in screen with the Microsoft button already there; the password form still works. Re-runs sign in with the owner's password and refresh the data without touching the estate settings.
• README and demo/README.md describe the new flow; the portal screenshot and walkthrough recording are current.

Release notes

• Both the portal and the receiver images ship in this release.
• Existing users are offered the new tour once.
• The window preference and pinned pages are stored per account.

Verification

• Portal: 652 tests. Receiver: 310 tests.
• Walked in Chrome on the demo stack at desktop, medium and phone widths in both themes, including the single sign-on flow end to end and the printed PDFs.