Rename the project spec and update every reference to it

The charter file carried a tool-specific name while being the repository's own
document: mission, non-negotiable constraints, the pinned stack, repo
conventions and phase status, cited as authority by thirty files across the
agent, api, deploy, docs, search and terraform trees.

PROJECT-SPEC.md says what it is. All 42 references are updated in the same
commit, including the relative link in docs/status.md, so nothing points at a
filename that no longer exists.

deploy/README.md

@@ -1,7 +1,7 @@
 # deploy
 
 Kubernetes deployment for Cairn OBS, added in Phase 4 (`/deploy` was
-deliberately stubbed through Phase 3 -- see `/CLAUDE.md`'s Phase 3
+deliberately stubbed through Phase 3 -- see `/PROJECT-SPEC.md`'s Phase 3
 non-goals). Two pieces:
 
 - `operator/` -- a small Go controller-runtime Operator managing one CRD
@@ -18,7 +18,7 @@ map of per-tenant ClickHouse connection pools via `internal/chrunner`;
 `search` holds a map of per-tenant Tantivy indices via
 `src/registry.rs`) -- not at the Kubernetes layer. This directory is
 **not** "one Deployment per tenant" or a general multi-cluster system;
-that's an explicit Phase 4 non-goal (see `/CLAUDE.md`). What it *does*
+that's an explicit Phase 4 non-goal (see `/PROJECT-SPEC.md`). What it *does*
 add:
 
 - A `Tenant` CRD + controller (`operator/internal/controller`) that

deploy/helm/cairnobs/README.md

@@ -99,7 +99,7 @@ unconditional by design, no disable switch.
 both tenants reached `status.phase: Active` with real credentials.
 
 This proves Phase 4's "two tenants... with their own users, roles,
-dashboards" exit criteria (`/CLAUDE.md`) end to end at the deployment-
+dashboards" exit criteria (`/PROJECT-SPEC.md`) end to end at the deployment-
 topology layer: `-provision-tenant` (`enterprise/internal/
 tenantprovision`) is what actually creates each tenant's ClickHouse
 database/user/grant and marks it active in `rbacstore`; running inside

deploy/helm/cairnobs/values.yaml

@@ -94,7 +94,7 @@ search:
   # A second replica would form a second, independent consumer instance
   # against the same partitions with no coordination -- correctness,
   # not just resource waste, is the reason this isn't a `replicas` knob
-  # yet. Matches CLAUDE.md's Phase 4 non-goal: "no general multi-cluster
+  # yet. Matches PROJECT-SPEC.md's Phase 4 non-goal: "no general multi-cluster
   # orchestration."
   replicas: 1
   resources: {}

deploy/operator/api/v1alpha1/tenant_types.go

@@ -18,7 +18,7 @@ import (
 // internal/controller/tenant_controller.go's doc comment for how
 // TenantReconciler derives Phase/Conditions from those fields rather
 // than fabricating its own "provisioned" claim. This is the "lightweight
-// unification" named in CLAUDE.md/docs/phase-4-runbook.md's "two
+// unification" named in PROJECT-SPEC.md/docs/phase-4-runbook.md's "two
 // independent provisioning mechanisms" gap: -provision-tenant stays the
 // real actor; this operator's reconcile loop never touches Postgres or
 // ClickHouse and gained no new credentials.