[rami-hatoum]

What this changes

Before launch nothing stored is carried over: a ledger made in another layout of its tables is refused at start, and the person deletes it. Until now that rule was enforced table by table, for the content tables and kept_secrets alone, by comparing their columns with the columns this server keeps, while every other table and index the ledger makes was created with IF NOT EXISTS and never checked, and a refusal named columns, which nobody can act on.

Now one number names the layout of everything the ledger makes.

• ledgerLayout is one constant in the ledger, raised by hand with any change to a table or an index the ledger itself creates. A test pins the catalog of a fresh SQLite ledger, every table and index that is the ledger's own with its statement, Emmett's left out as its own schema's concern, and fails in words that say to raise the number and pin again, so a change to the layout cannot pass unnumbered.
• Written once, at creation, before any table. SQLite keeps it in PRAGMA user_version, as the first step of the store's migrate; PostgreSQL in the one row of ledger_layout, inside Emmett's migration transaction right after the advisory lock is taken, so servers that start together agree and a refusal rolls everything back.
• One rule at every open. A database in the layout kept opens, and what it lacks is created as before. A database with no number and no table at all is new: it is given the number. A database in another layout, or one that holds tables but no number, is refused as LedgerLayoutRefused, which carries the layout found, or none, and the layout kept. The per-table column checks and the test fakes that answered column queries are gone.
• The server says it in its own words, as before: where the ledger is kept, that it was made by another version of Auto Runtime, which keeps the ledger in layout n and cannot read a ledger in layout m, or one that carries no layout number, then what to do and where to ask. The terminal notice ends with the help line.
• The docs no longer promise a migration. The self-host pages say that a release which keeps the ledger's layout opens it as it is, and that before launch one which changes it refuses the ledger and says what to delete, or to point DATABASE_URL at an empty database.

Every ledger made before this release carries no number, so the first start on it refuses it with the notice that names the files to delete, or the database to empty. The word is layout, since shape names the JSON Schema of a definition's output and version names the runtime's release in the same sentence.

Tests

• The layout behaviour runs on both stores: a new database is given the number and opens again in it; a database in another layout is refused with the layout found and kept, in the refusal's words, and left as it was; a database that holds a table but no number is refused the same way and left as it was.
• The pin test fails, with its own words, when a column is added to kept_secrets.
• The PostgreSQL hook is covered on fakes without a database, and the ledger's suite ran against PostgreSQL 18 with and without the connection URL at 100% coverage.
• The server's tests that start a real runtime on a ledger of another layout read what it prints, in a terminal and as a server.

Checklist

• The PR title is a conventional commit with a workspace scope, such as feat(reasoning): .... It becomes the squash commit and the changelog entry.
• pnpm check passes locally, with every file at 100% coverage.
• I've signed the Contributor License Agreement (the CLA bot asks on your first PR).