cherry-pick: Preserve 5.2 rollback compatibility for first-time table creates (conflicts → v5.3)

[github-actions]

Cherry-pick of PR #3118 onto `v5.3` produced conflicts on commit(s): `4db030f2a0b8f4d064dfdf60446b4181ec597a40 b8fca4e 5f8f49e`.

Resolve the conflict markers on branch `cherry-pick/v5.3/pr-3118` and merge this PR.

@claude please review branch `cherry-pick/v5.3/pr-3118` and suggest a patch that resolves the conflict markers (<<<<<<< / ======= / >>>>>>>) introduced by cherry-picking PR #3118 onto `v5.3`. Post the suggested patch as a comment here — do not push.

Resolution on v5.3

The conflict markers are resolved in two new commits on top of the Action's commits. No history was rewritten. The resolution started from #3118's squashed diff on main (4dba9f5), not from the nested markers.

• Dropped: main-only Stamp table generations and keep a durable drop marker so a peer that missed a replicated drop_table cannot bring the table back #2962 code. The large databases.ts conflict block was the drop-marker and createdTime code from Stamp table generations and keep a durable drop marker… (#2962). That PR is milestoned v5.4 and is not on v5.3, so the block is gone. This removes writeTableDropMarker, getTableDrops, recordTableDrop, tableLifecycleTime, the createdTime stamps and the related helpers.
• Kept: Preserve 5.2 rollback compatibility for first-time table creates #3118's untimed name-history row. Before a create picks bare names (the names 5.2 can read), Preserve 5.2 rollback compatibility for first-time table creates #3118 checks whether the name was used before: a /dropped/<table> row, a journal row, or a T/ column family (check in declareTable). On main, only Stamp table generations and keep a durable drop marker so a peer that missed a replicated drop_table cannot bring the table back #2962's drop-completion code writes that row. On v5.3, recordTableNameHistory writes the untimed { table, tableId } row Preserve 5.2 rollback compatibility for first-time table creates #3118 added on main. It runs at both RocksDB drop-completion points, under the catalog lock and before the tombstone is removed: retireRocksStores in Table.ts and completeInterruptedDrop. Without it, a recreate after the journal is cleaned up (about 2 s) falls back to bare names, and naming depends on timing. Look hardest here.
• Loader skip. The v5.3 catalog loader skips /dropped/ rows. Downgrading to 5.2 or 5.3.0/5.3.1: the old loader sees a table '' with no primary key and skips it with one warning. 5.2 already does this for /generation/ rows. Upgrading to 5.4: the row is read as its untimed marker, and a timed drop overwrites it.
• Tests and docs.
  • v5.3's dropTable() takes no options, so the getTableDrops assertion and the ignored localOnly arguments were removed.
  • New test covers a drop completed at boot, plus the loader skip.
  • The design notes keep v5.3's section heading. The #3118 note describes the v5.3 row instead of the lifecycle stamps.

Every other production hunk matches #3118's squash on main.

❓ Your call: the backport adds one stored row type (/dropped/<table>) to the 5.3 patch line. You chose this (option A) over counting only journal rows and column families, which would make recreate naming timing-dependent and require rewriting about 5 of #3118's tests.

❓ Your call: two pre-existing defects are left as they are on main and recorded for follow-up there:

• Orphan index column family. A crash before publish, then a 5.2 rollback, then a recreate with a different index set leaves an empty index column family (publishedCreate removes the creating journal).
• Stale drop deletes the replacement's catalog. The operations-API dropTableMeta still runs after a stale drop, deleting a replacement table's catalog rows. This one is older than Preserve 5.2 rollback compatibility for first-time table creates #3118.

Fixing either on v5.3 alone would make this backport differ from main.

Verification

• Locally (RocksDB): dropTableGeneration 24/24, and the ghost-table and cross-worker drop files pass. LMDB passes on the same files. Full test:unit:resources passed on c6ff208: 4024 passing, 0 failing.
• Mutation checks: removing the Table.ts write fails 2 of Preserve 5.2 rollback compatibility for first-time table creates #3118's tests. Removing the completeInterruptedDrop write, or the loader skip, fails the new test.
• CI was dispatched on 8e83d2d: Integration Tests (Node 24) ✅ (24/24 jobs, on the Node 24, uWS, Bun and Windows legs) and Unit Test (Node 24) ✅ (7/7 jobs). On the Node 24 leg, first-create-downgrade ran the real 5.2.15 round trip and passed. The tables it drops leave /dropped/ rows, so 5.2 booted with them present.
• The PR-triggered Unit Test (Node.js v26) fails 7 tests on Node 26.11.1 (withNodeAdapter ×4, install_node_modules dry-run ×3). These are v5.3's own baseline failures, and v5.3's push runs of unit-test.yml are red too. The Node 22 and 24 legs pass.
• Pre-push review (codex, gemini, cursor-composer, harper-domain; one full round, one delta round): 2 findings fixed. The rest are declined or deferred, and they concern code that is identical to main's Preserve 5.2 rollback compatibility for first-time table creates #3118 or older.

— Claude Opus 5.5

🤖 Generated with Claude Code

https://claude.ai/code/session_01QYAaU3uVxkbjHe19UNWRfK

Related PRs: #3118 overlaps, #2962 overlaps, #3119 overlaps, 17 others independent

_{Review-Coverage: authored=claude; ran=gemini,codex,cursor-composer; adjudicated=domain; blocked=cursor-grok(failed); declined=cursor-kimi,cursor-muse; rounds=2; full=1 @ 8e83d2d}

_{Review-Attention: deep ~30m (critical: Table.ts, databases.ts; decisions: main-first-follow-ups, keep-legacy-writer-comment) @ 8e83d2d}