ci: an integration lane, so the migrations are finally run by something

26 Alembic revisions and none had ever been executed by CI. `alembic upgrade
head` ran for the first time when the operator's container started, and the
schema the migrations build had never been checked against the models that read
it. M13 dropped three columns and rebuilt a STORED GENERATED column with nothing
watching but a server boot.

Copied from FabledScribe's `integration` job, which had already solved the parts
that are easy to get wrong — and which are family rules precisely because they
were: a separator-free job key with no `name:` (act_runner derives the service
container name from the truncated display name, and the discovery step filters
`docker ps` by it), bridge-IP resolution because service hostnames aren't
routable on this runner, and a Python readiness wait because `run:` is busybox
sh with no `/dev/tcp`.

`postgres:16-alpine` to match the production compose. The schema is built by
real migrations, never metadata.create_all — that step IS the migration test.

Six tests, each pinning something that has only ever been checked by hand:

- an ORM insert against the migrated schema, which is the model/migration
  agreement nothing has verified until now;
- `notes.title`, `notes.kind` and `note_revisions.title` are actually gone, and
  `note_links` with them — a silently no-op migration shows up here;
- the rebuilt `search_vector` indexes both the name and the body, which matters
  because 0026 had to DROP and recreate a generated column rather than alter it;
- a note keeps its body AND its items, the shape step 2 made normal;
- `_apply_note_items` leaves items alone when a change doesn't mention them —
  the data-loss path step 2 removed, pinned so its return would be caught;
- a note with no body is still named by its first item, the hole that made
  removing the title unsafe until checklists stopped being their own kind.

Runs for visibility; does not gate the build, matching `test` and Scribe.

No local equivalent: running it means standing up Postgres on the workstation,
which rule 12 reserves for an explicit request. Documented in ci-requirements
alongside the Rust, Kotlin and frontend gates.

ci-requirements.md

@@ -73,6 +73,43 @@ entirely on `ci-python:3.14`.
   `…/actions/artifacts/{id}/zip`. Note the workstation has no `unzip` — use
   `python3 -m zipfile -e`.
 
+## The integration lane
+
+Added 2026-08-23. Before it, `alembic upgrade head` ran for the first time when the
+operator's container started — 26 revisions, none of them ever executed by CI — and
+the schema the migrations build had never been checked against the models that read
+it. M13 dropped three columns and rebuilt a STORED GENERATED column with nothing
+watching.
+
+Copied from FabledScribe's `integration` job, which had already solved the awkward
+parts. Three of them are family rules for a reason:
+
+- **Job key `integration`, no `name:`** (rule 80). act_runner derives the service
+  container's name from the truncated job DISPLAY name, and the discovery step filters
+  `docker ps` by it. A spaced or underscored name breaks the filter.
+- **Service hostnames are not routable** on this runner (rule 79), so the step resolves
+  the Postgres container's bridge IP with `docker ps --filter` + `docker inspect` and
+  builds `THOUGHTSYNC_DATABASE_URL` from it. `postgres:5432` will not connect.
+- **`run:` is busybox sh** (rule 81) — no `/dev/tcp` — so the readiness wait is a small
+  Python heredoc. Its terminator must dedent to column 0 after YAML strips the block
+  indent; check with `yaml.safe_load` and print the `run` string if you edit it.
+
+`postgres:16-alpine`, matching the production compose, so the schema is proven against
+the Postgres it will actually meet. The schema comes from **real migrations, never
+`metadata.create_all`** (rule 82): testing a schema no deployment has ever seen proves
+nothing, and that `alembic upgrade head` step IS the migration test — a broken revision
+fails the job there, before it can fail a container start.
+
+Tests are marked `integration` (registered in `pyproject.toml`); the unit lane runs
+`-m "not integration"` and stays DB-free. Data resets with `TRUNCATE ... CASCADE`
+BEFORE each test rather than after, so a failure leaves its rows behind to look at.
+
+Like `test`, it runs for visibility and does **not** gate the build.
+
+There is no local way to run it — that would mean standing up Postgres on the
+workstation, which rule 12 reserves for an explicit request. This lane is verified in
+CI.
+
 ## Desktop (Tauri) lane — separate workflow
 
 The Tauri desktop client (`desktop/`) builds in its own workflow,