Migration v22 is claimed by #253; a second branch claiming it silently no-ops its own ALTERs

[pseudoseed]

Split from the #253 3-way review. Not a change to that PR.

What

packages/codev/src/agent-farm/db/index.ts numbers migrations with a single
GLOBAL_CURRENT_VERSION and a _migrations row per version. #253 takes v22
(architect.harness / architect.model).

builder/pir-241 is in flight on the same files. If it — or any other branch — also
claims v22, whichever merges second loses: its block is skipped because a v22 row is
already recorded, and its ALTERs never run. Nothing reports this. The columns are simply
absent, and the first write naming them fails at runtime, far from the cause.

Order

#253 merges first and owns v22. 241 rebases onto it and takes v23.

Worth considering separately

The version number is a shared mutable counter with no collision detection, and this is the
second spec to run two branches across it. A migration keyed by a name rather than by an
integer, or a check that refuses to record a version whose statements it did not run, would
make the collision loud instead of silent. Not required for either PR.

[pseudoseed]

Merge order reversed. #258 (issue #241) merges FIRST — it is ready and it is the critical
path; #253 still owed its live run when this was filed.

So #253 rebases onto main after #258 lands, and takes whatever version #258 leaves free.
If #258 claims v22, #253 becomes v23; the GLOBAL_CURRENT_VERSION bump, the
applyArchitectAgentMigration call site and the send-architect-identity.test.ts source
guard all move with it, and the pre-v21 fixture in spec-146-phase-8-thread-identity.test.ts
already applies the migrations in sequence rather than by number.

The body above still describes the collision correctly — only which branch absorbs it has
changed.