rename(phase 1): CapaKraken → Nexus across code, UI, docs, CI

- @capakraken/* → @nexus/* across 12 packages (root + 11 workspaces),
  1551 import lines migrated via codemod
- User-visible brand strings renamed (emails, page titles, PWA
  manifest, mobile header, MFA backup-codes header, tooltips, signin
  page, invite page, weekly digest, install prompt)
- TOTP issuer "CapaKraken" → "Nexus" (existing secrets still valid;
  re-enrollment relabels them in users' authenticator apps)
- Function rename: assertCapaKrakenDbTarget → assertNexusDbTarget
- LocalStorage migration shim in apps/web/src/app/layout.tsx copies
  capakraken_* → nexus_* on first load (guarded by nexus_migrated_v1
  sentinel; runs once per browser, then never again)
- Service-worker cache name capakraken-v2 → nexus-v2 with one-time
  caches.delete('capakraken-v2') from the same shim
- Email-domain fixtures @capakraken.{dev,app} → @nexus.{dev,app} in
  seed data, e2e specs, SMTP default fallback
- Dockerfile.dev / Dockerfile.prod / all .github/workflows/*.yml
  pnpm --filter @capakraken/* → @nexus/*
- README, CLAUDE.md, LEARNINGS.md, all docs/*.md, .env.example,
  tooling/deploy/.env.production.example brand sweep

Phase 1 deliberately leaves untouched (handled in Phase 3 cutover):
- PostgreSQL DB name "capakraken" and POSTGRES_USER "capakraken"
- Volume names capakraken_pgdata etc.
- Compose project name "capakraken" / "capakraken-prod"
- db-target-guard default expectedDatabase
- env-var CAPAKRAKEN_EXPECTED_DB_NAME
- Container DNS names in docker-compose.ci.yml

Quality gates green: pnpm typecheck (7/7), pnpm test:unit (7/7),
pnpm lint (0 errors), check:exports/imports/architecture all pass.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/cicd-target-architecture.md

@@ -2,7 +2,7 @@
 
 ## Goal
 
-This document describes the canonical release path for CapaKraken.
+This document describes the canonical release path for Nexus.
 
 The release model is now:
 
@@ -16,7 +16,7 @@ The release model is now:
 
 ### 1. Pull Request Validation
 
-The main [ci.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/ci.yml) workflow remains the merge gate for:
+The main [ci.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/ci.yml) workflow remains the merge gate for:
 
 - architecture guardrails
 - typecheck
@@ -27,26 +27,26 @@ The main [ci.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/c
 
 ### 2. Automatic Image Release
 
-[release-image.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/release-image.yml) now runs automatically on every push to `main` and can still be started manually for rebuilds or tag overrides.
+[release-image.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/release-image.yml) now runs automatically on every push to `main` and can still be started manually for rebuilds or tag overrides.
 
-It publishes two images from [Dockerfile.prod](/home/hartmut/Documents/Copilot/capakraken/Dockerfile.prod):
+It publishes two images from [Dockerfile.prod](/home/hartmut/Documents/Copilot/nexus/Dockerfile.prod):
 
 - `ghcr.io/<owner>/<repo>-app:sha-<commit>`
 - `ghcr.io/<owner>/<repo>-migrator:sha-<commit>`
 
 ### 3. Staging Promotion
 
-[deploy-staging.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-staging.yml) copies the canonical deploy bundle to the staging host:
+[deploy-staging.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-staging.yml) copies the canonical deploy bundle to the staging host:
 
-- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/capakraken/docker-compose.prod.yml)
-- [tooling/deploy/deploy-compose.sh](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy-compose.sh)
-- the rest of [tooling/deploy](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/README.md)
+- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/nexus/docker-compose.prod.yml)
+- [tooling/deploy/deploy-compose.sh](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy-compose.sh)
+- the rest of [tooling/deploy](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/README.md)
 
 GitHub Actions also writes a short-lived `deploy.env` containing `APP_IMAGE`, `MIGRATOR_IMAGE`, and the host port.
 
 ### 4. Host-Side Deployment
 
-On the target host, [deploy-compose.sh](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy-compose.sh):
+On the target host, [deploy-compose.sh](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy-compose.sh):
 
 1. loads `.env.production` and `deploy.env`
 2. validates the rendered compose file
@@ -60,7 +60,7 @@ The host does not build application code from Git anymore.
 
 ### 5. Production Promotion
 
-[deploy-prod.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-prod.yml) repeats the exact staging flow with the same image tag after staging acceptance.
+[deploy-prod.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-prod.yml) repeats the exact staging flow with the same image tag after staging acceptance.
 
 That keeps staging and production on the same artifact instead of rebuilding.
 
@@ -88,13 +88,13 @@ That keeps staging and production on the same artifact instead of rebuilding.
 
 The canonical host-side inputs are:
 
-- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/capakraken/docker-compose.prod.yml)
+- [docker-compose.prod.yml](/home/hartmut/Documents/Copilot/nexus/docker-compose.prod.yml)
 - `.env.production`
 - `deploy.env`
 
-`.env.production` holds long-lived runtime configuration and secrets. The example file is [tooling/deploy/.env.production.example](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/.env.production.example).
+`.env.production` holds long-lived runtime configuration and secrets. The example file is [tooling/deploy/.env.production.example](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/.env.production.example).
 
-`deploy.env` is short-lived deployment metadata. The example file is [tooling/deploy/deploy.env.example](/home/hartmut/Documents/Copilot/capakraken/tooling/deploy/deploy.env.example).
+`deploy.env` is short-lived deployment metadata. The example file is [tooling/deploy/deploy.env.example](/home/hartmut/Documents/Copilot/nexus/tooling/deploy/deploy.env.example).
 
 Important invariants:
 
@@ -107,7 +107,7 @@ Important invariants:
 Release environments must run migrations through the `migrator` image, which executes:
 
 ```bash
-pnpm --filter @capakraken/db db:migrate:deploy
+pnpm --filter @nexus/db db:migrate:deploy
 ```
 
 `db:push` remains a local-development tool, not a production rollout mechanism.
@@ -127,9 +127,9 @@ This assumes schema changes follow backwards-compatible expand-and-contract roll
 The standard production update is:
 
 1. merge to `main` after CI is green
-2. let [release-image.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/release-image.yml) publish `sha-<commit>` images
-3. deploy that tag to staging through [deploy-staging.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-staging.yml)
+2. let [release-image.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/release-image.yml) publish `sha-<commit>` images
+3. deploy that tag to staging through [deploy-staging.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-staging.yml)
 4. validate staging
-5. promote the same tag through [deploy-prod.yml](/home/hartmut/Documents/Copilot/capakraken/.github/workflows/deploy-prod.yml)
+5. promote the same tag through [deploy-prod.yml](/home/hartmut/Documents/Copilot/nexus/.github/workflows/deploy-prod.yml)
 
 The important property is artifact identity: staging and production run the same image, not two separate builds.