Rebrand: Sentry -> Cairn OBS

Full rebrand across cosmetic branding, code identifiers, and
infrastructure/data-plane naming, using the supplied Cairn OBS logo
package. Cosmetic: favicon/logo swap (also closes a stale license-audit
finding -- the old favicon was SvelteKit's unreplaced scaffold logo),
new centered welcome landing page, larger/legible sidebar logo, page
titles, CLAUDE.md/README/docs prose.

Code identifiers: Go module path github.com/sentry/sentry ->
github.com/cairnobs/cairnobs across all 13 modules and ~91 files (protoc
regenerated); Rust crates sentry-agent/sentry-parser/sentry-search ->
cairnobs-*; CLI sentryctl -> cairnobsctl; Terraform provider fully
renamed (sentry_dashboard etc. -> cairnobs_dashboard, provider type,
env vars); every session/auth cookie name; agent config paths and
Windows service identity.

Deliberately preserved: the gRPC wire protocol's protobuf packages
(sentry.logs.v1, sentry.agent.v1) and their Go import directory
(proto/sentry/...) -- renaming the wire-level package would break every
currently-deployed agent binary (confirmed two real hosts, including
mail.inbuxa.com, are actively streaming through this exact contract)
until rebuilt and redeployed in lockstep with an ingest cutover. Only
the Go module path wrapping the generated code changes.

Infrastructure: every docker-compose container name (root and three
component-level compose files); the Helm chart (directory, Chart.yaml,
named-template helpers, all templates, values.yaml image repos);
Kubernetes Operator (CRD group sentry.io -> cairnobs.io, both CRD YAML
files, Go identifiers, RBAC markers); the coupled enterprise/tenantcrd
package. Caught and fixed real path-coupling bugs along the way: the
Helm chart's search/ingest volume mounts and the dev-only-credential
detection constant vs. docker-compose.yml's literal values had to move
together or a security warning would have silently stopped firing.

Data plane: Postgres database sentry_metadata -> cairnobs_metadata and
role sentry -> cairnobs; ClickHouse database sentry -> cairnobs; Kafka
topic sentry.logs.raw -> cairnobs.logs.raw and its consumer groups.
Source-level defaults, docker-compose.yml, and every migrate.sh/
provision script default updated together; already-applied migration
files left untouched per this repo's immutable-migration convention.

Verified at every layer: all 13 Go modules build/vet/test clean, both
Rust workspaces (agent, search) build/clippy/test clean, npm run check/
build clean, docker compose config validates on all four compose files.
Live-verified against a real docker stack multiple times through this
work, including a final fresh-volume run confirming the actual renamed
Postgres database/role, ClickHouse database, and Kafka topic all work
end to end with a real login and query, zero console errors.

docs/agent-heartbeat-monitoring.md

@@ -10,7 +10,7 @@ reachable, and how quickly the platform notices when it stops.
 
 The agent's transport has always been push-only, by design — it dials
 *out* to `ingest` over mTLS; nothing in the platform ever dials into an
-agent (see `agent/sentry-agent/src/grpc.rs`'s doc comment). Making
+agent (see `agent/cairnobs-agent/src/grpc.rs`'s doc comment). Making
 liveness detection a true pull (the platform reaching into every remote
 host on a schedule) would mean every agent needs a reachable address and
 an open inbound port — a real problem for hosts behind NAT or with
@@ -28,7 +28,7 @@ model this reuses unchanged.
 
 ## Configuring the heartbeat
 
-`agent/sentry-agent/config/agent.example.toml`:
+`agent/cairnobs-agent/config/agent.example.toml`:
 
 ```toml
 [heartbeat]
@@ -40,7 +40,7 @@ The heartbeat record is sent through the exact same `PushBatch` RPC and
 mTLS identity every log line uses, bypassing the batch buffer (`[batch]`
 `max_size`/`flush_interval_ms`) so it's punctual rather than subject to
 batching delay. It's distinguished from real log data purely by an
-attribute — `sentry.heartbeat=true` — not by a fake `service` value, so
+attribute — `cairnobs.heartbeat=true` — not by a fake `service` value, so
 it never pollutes service-based dashboards or faceting. `message` is the
 literal string `"agent heartbeat"`.
 
@@ -55,7 +55,7 @@ heartbeat doesn't look like a false absence):
 curl -X POST http://localhost:8081/rules -H 'Content-Type: application/json' -d '{
   "name": "web-01 unavailable",
   "description": "fires when web-01 misses its heartbeat window",
-  "query": "earliest=-3m host=web-01 sentry.heartbeat=true",
+  "query": "earliest=-3m host=web-01 cairnobs.heartbeat=true",
   "query_language": "spl",
   "condition_type": "absence",
   "eval_interval_seconds": 60,
@@ -123,7 +123,7 @@ this was simply never exercised in this specific way before) and a
 curl -X POST http://localhost:8081/rules -H "Content-Type: application/json" -d "{
   \"name\": \"fleet degraded\",
   \"description\": \"fires when fewer than 3 of the expected fleet hosts have heartbeated recently\",
-  \"query\": \"SELECT count(DISTINCT host) AS active_agents FROM logs WHERE timestamp > now() - INTERVAL 3 MINUTE AND attributes['sentry.heartbeat'] = 'true' AND host LIKE 'web-%'\",
+  \"query\": \"SELECT count(DISTINCT host) AS active_agents FROM logs WHERE timestamp > now() - INTERVAL 3 MINUTE AND attributes['cairnobs.heartbeat'] = 'true' AND host LIKE 'web-%'\",
   \"query_language\": \"sql\",
   \"condition_type\": \"threshold\",
   \"comparator\": \"lt\",
@@ -172,8 +172,8 @@ wanted, not duplicated as a one-off script now.
 ## Verified live
 
 This exact flow was run end-to-end against a live stack in this repo: a
-real `sentry-agent` binary, heartbeat interval 5s, connected to a real
-`ingest`; an absence rule (`earliest=-45s host=... sentry.heartbeat=true`,
+real `cairnobs-agent` binary, heartbeat interval 5s, connected to a real
+`ingest`; an absence rule (`earliest=-45s host=... cairnobs.heartbeat=true`,
 `eval_interval_seconds=30`, `for_minutes=0`) created via the REST API
 above; the agent process killed; the rule transitioned `ok` → `firing`
 within one evaluation cycle (`condition_true_since`/`fired_at` both set