Say that Phase 4 shipped, and that the environment proving it is gone (#7)

The status file and the README both still said Phase 4 was not shipped
because the environment had lost Docker and database access partway
through, and that only the audit-logging guarantees had been confirmed
against a live database. That stopped being true some time ago.
phase-4-runbook.md records the opposite in detail: Docker access came
back, a real docker-compose stack ran with real ClickHouse and Postgres
and two provisioned tenants, a local kind cluster ran the Helm chart end
to end, and both SSO protocols were verified against a real Auth0 tenant
with full browser round trips. Eight real bugs came out of that, six from
compose and two from the chart's first real install -- none of them
findable without the infrastructure.

PROJECT-SPEC.md sends readers to status.md and tells them to read it
before assuming a capability works end to end, so the one file that is
meant to be authoritative was the one understating the project by the
widest margin.

Correcting it matters more now than it would have last week, because the
evidence cannot be regenerated: proto.cairnobs.org and the VPS under it
were retired on 2026-09-04, taking the mTLS CA, the server certificate
and six enrolled agents with them. The runbooks are what is left.

Three gaps are now stated rather than implied:

The prototype is gone, so none of this can be re-run today without
building one. The DNS was kept for that; the certificates deliberately
were not.

demo.cairnobs.org is live and is not evidence for Phase 4. It runs
COMPOSE_PROFILES=single-tenant, so it exercises the OSS path and says
nothing about RBAC, tenant isolation or per-tenant ClickHouse. A healthy
demo proving multi-tenancy is exactly the wrong inference to leave
available.

SSO has been tried against one IdP and one local kind cluster, not two
IdPs and not a production-grade cluster.

The Terraform entry now names its cause instead of pointing at another
file: alerting exposes no PUT for rules or targets, and neither
rulestore.Store nor notifystore.Store has an Update method to wire one
to, so Terraform destroys and recreates -- which resets alert_state and
delivery-log continuity.

README.md

@@ -122,18 +122,25 @@ Full per-phase detail is in [`docs/status.md`](docs/status.md).
 | 1 | Windows Event Log + journald, SQL and full-text paths | Shipped |
 | 2 | Unified query language across both stores | Shipped |
 | 3 | Dashboards, alert rules, notification delivery | Shipped |
-| 4 | RBAC, tenant isolation, audit logging, per-tenant ClickHouse | **In progress** |
+| 4 | RBAC, tenant isolation, audit logging, per-tenant ClickHouse | Shipped |
 | 5 | Frontend redesign and design system | Shipped |
 | 6 | License compliance audit and remediation | Shipped |
 | 7 | AI-assisted query authoring | Shipped |
 
-**Phase 4 is not shipped.** The code is built and tested, but the environment
-lost Docker and database access partway through, so only the audit-logging
-guarantees were confirmed against a live database. The rest compiles and skips
-cleanly when no live database is configured, but is otherwise unverified — see
-the verification-status section of
+**Phase 4 is shipped, and the environment that proved it is gone.** Every
+control the phase defines was verified against real infrastructure at least
+once — a docker-compose stack with real ClickHouse and Postgres, a local `kind`
+cluster, and both SSO protocols against a real Auth0 tenant — finding eight
+bugs that no amount of Docker-free testing could have caught. The prototype
+VPS was retired on 2026-09-04, so that verification is a record rather than
+something you can re-run: see
 [`docs/phase-4-runbook.md`](docs/phase-4-runbook.md).
 
+Two limits worth stating plainly. SSO has been tried against one IdP, not two,
+and no production-grade cluster has run this. And `demo.cairnobs.org` is **not**
+evidence for any of it — the demo runs the single-tenant profile, so it
+exercises the OSS path and says nothing about RBAC or tenant isolation.
+
 The Windows agent code (`EvtSubscribe`, ETW, service registration) has never
 run on real Windows — no Windows toolchain existed in the build environment.
 ETW additionally sits behind a feature flag, since it needs elevated