chore(db): stop creating the legacy tale_platform database

[larryro]

Why

tale_platform is the Convex-era database. Nothing in the 0.5 product reads it, yet services/db/init-scripts/02-create-convex-database.sql still created it (with uuid-ossp + pg_trgm) on every start of every tale-db container — db and knowledge-db run the same image and the same scripts. Every 0.5 install to date therefore carries an empty copy.

What changes

• Delete 02-create-convex-database.sql. The entrypoint loops over the remaining 01/03/04 scripts unchanged and still touches /tmp/.db_ready only after the scripts and the role's migrations succeed. 03/04 keep their numbers: the filenames are referenced from compose.yml:347 and both knowledge baselines, so renumbering would churn three more files for no behaviour.
• Comments and READMEs that still said Convex owns the platform DB now say what is true: tale_app is migrated by the platform backend at boot, migrations/db/ is intentionally empty. Also dropped the stale services/convex/ line from Dockerfile.dockerignore.
• INSTANCE_NAME=tale_platform — the Convex instance name pinned to this database — is exported by env.sh, defaulted by dev-engine.ts and set in .env.test, and read by nothing (rg INSTANCE_NAME finds no consumer). Removed; the three remaining Convex comments in env.sh and the SSL-mode rationale in deployment-stores.tsx now state the 0.5 reason (the backend pins the app-Postgres connection test to sslmode=prefer, domains/deployment/service.ts:448).
• Guard: services/platform/tests/guards/db-init-scripts.guard.test.ts pins the init scripts to exactly tale_app + tale_knowledge and rejects any mention of tale_platform, so the retired store cannot creep back and a new database cannot appear without the platform learning to use it.
• Docs: operator note in self-hosted/operate/upgrades.md (en, then de/fr authored natively) under the 0.4 → 0.5 cutover section.

Existing deployments

Nothing is dropped automatically. The init scripts are CREATE … WHERE NOT EXISTS only, so an existing volume keeps its tale_platform until the operator drops it by hand. The note tells them how:

The legacy tale_platform database. Every tale-db container used to create an empty tale_platform database on start — the database the bundled Convex service used in 0.4, which nothing in 0.5 reads. Fresh installs no longer create it, and nothing drops it for you: an instance first deployed on an earlier 0.5 release still carries it, and so does a reused 0.4 host. It is harmless. Once you are sure you need nothing from the Convex era, take a snapshot and drop it by hand — on db, and on knowledge-db where your stack runs one:

tale backup
docker compose exec db psql -U tale -d tale -c 'DROP DATABASE IF EXISTS tale_platform;'

Blast radius (rg -n "tale_platform|create-convex-database|convex")

Hit	Class	Action
services/db/init-scripts/02-create-convex-database.sql	(a) creates the DB	deleted
services/db/docker-entrypoint.sh :88 role comment, :111 + :200 bug-history comments, :183 platform-role echo	(c) describe Convex ownership / the deleted script	reworded to tale_app + backend-at-boot
services/db/Dockerfile migrations comment; Dockerfile.dockerignore services/convex/	(c)	reworded / stale line dropped
services/db/README.md, services/db/migrations/db/README.md	(c)	two databases described honestly; retired DB pointed at the docs
services/platform/env.sh INSTANCE_NAME export + 3 Convex comments; scripts/dev-engine.ts default; .env.test	(a) pins the Convex instance name to the DB; no reader	removed / reworded
deployment-stores.tsx SSL-mode rationale (Convex driver + INSTANCE_NAME)	(c)	reworded to the verified 0.5 reason
tools/cli/** (SNAPSHOT_VOLUMES, CONFIG_VOLUME='convex-data', breaking-cutover-guard.ts, compose generators)	(b) legacy/upgrade path	preserved, untouched — see below
compose.yml (convex-data volume + 04-create-app-database.sql comment), compose.dev.yml	correct after #3188	untouched
docs/*/self-hosted/{overview,operate/backups-and-restore,operate/upgrades}.md Convex mentions	correct history (convex-data volume, 0.4 cutover)	untouched; note added to upgrades.md
sanitize_secrets.ts admin-key regex + tale_platform|… example	redactor still scrubs Convex-shaped keys	untouched
services/platform/Dockerfile SANDBOX_STORAGE_INTERNAL_BASE_URL=http://convex:3210	the sandbox's convex network-alias contract	untouched
compose.sandbox-llm-gateway.dev.yml header, platform Dockerfile/entrypoint history comments, design/docs/*, configs/README.md, routes.ts convexStorage target, packages/* V8-boundary comments	Convex-era prose outside this PR's boundary (not about the database)	listed, untouched
Tests asserting three databases	none exist (container-smoke-test.ts probes tale + tale_knowledge only)	guard added instead

Proof — real image, both roles

docker build -f services/db/Dockerfile -t tale-db-retire-test . from this branch, then docker run … -e POSTGRES_USER=tale -e POSTGRES_PASSWORD=x -e POSTGRES_DB=tale -e DB_PASSWORD=x -e TALE_DB_ROLE=<role> on 127.0.0.1:55432/55433, waiting for /tmp/.db_ready.

TALE_DB_ROLE=platform — ready after 5 s, entrypoint log then psql -U tale -d tale -c '\l':

Running init scripts...
  01-init-extensions.sql
  03-create-knowledge-database.sql
  04-create-app-database.sql
TALE_DB_ROLE=platform: the tale_app schema is migrated by the platform backend at boot; no dbmate migrations to apply.
Database ready.

      Name      | Owner | Encoding | ... | Access privileges
----------------+-------+----------+-----+-------------------
 paradedb       | tale  | UTF8     |     |
 postgres       | tale  | UTF8     |     |
 tale           | tale  | UTF8     |     |
 tale_app       | tale  | UTF8     |     | =Tc/tale + tale=CTc/tale
 tale_knowledge | tale  | UTF8     |     | =Tc/tale + tale=CTc/tale
 template0      | tale  | UTF8     |     | =c/tale  + tale=CTc/tale
 template1      | tale  | UTF8     |     | =c/tale  + tale=CTc/tale
(7 rows)

TALE_DB_ROLE=knowledge — ready after 6 s; same \l (no tale_platform), and the corpus migrations applied:

Applying knowledge-corpus migrations...
  Applying private_knowledge migrations (dbmate)...   5 applied (…0001, 0003, 0006, 0007, 0008)
  Applying public_web migrations (dbmate)...          3 applied (…0002, 0004, 0005)
Knowledge-corpus migrations complete.
Database ready.

      schema       | applied
-------------------+---------
 private_knowledge |       5
 public_web        |       3

Existing-install simulation on the platform container: CREATE DATABASE tale_platform; → remove the marker → docker restart → ready again in 3 s and tale_platform still listed (nothing drops it automatically) → the documented command prints DROP DATABASE → re-run prints NOTICE: database "tale_platform" does not exist, skipping → \l = paradedb postgres tale tale_app tale_knowledge template0 template1.

(The ERROR: extension "postgis" is not available lines in the boot log come from ParadeDB's upstream 10_bootstrap_paradedb.sh; this image strips PostGIS on purpose — pre-existing and unrelated.)

Throwaway containers and images were removed afterwards.

Gates observed

• bash -n services/db/docker-entrypoint.sh, bash -n services/platform/env.sh — OK
• bunx vitest --run --project server tests/guards/db-init-scripts.guard.test.ts — 2/2 passed
• bunx oxlint --type-aware on the guard, dev-engine.ts, deployment-stores.tsx — 0 findings
• bunx oxfmt --check on touched files — clean
• bun run --filter @tale/docs test — 30 files / 194 tests passed (before and after the final wording pass)
• bunx knip — exit 0 (one pre-existing cron-parser config hint, unrelated)
• tools/cli untouched → its suite not run

Preserved on purpose

• tools/cli upgrade/backup/restore path. The CLI never names tale_platform: tale backup/tale restore snapshot whole volumes (db-data, convex-data, object-store-data, caddy) as tars, so a volume with or without the database restores identically, and breaking-cutover-guard.ts still refuses an in-place 0.4 → 0.5 upgrade. There was nothing to keep tolerant of the database's absence, so nothing changed there.
• convex-data volume name everywhere (compose, CLI generators, backups, docs) — the org config store, kept so no operator migrates a volume for a rename.
• Admin-key redaction in sanitize_secrets.ts — still worth scrubbing from logs.