A thread that declared a table's TTL never adopts a later saved TTL from another thread #4240

Summary

A thread whose own schema declaration (or application code) set a table's expiration/eviction never adopts a later value another thread saves to the catalog. It keeps its own value until it declares the table again or restarts.

Mechanism

• Table._adoptCatalogExpiration returns early when ttlDeclaredBySchema or ttlConfiguredByApplication is set (resources/Table.ts).
• ttlDeclaredBySchema is set by any schema declaration that names a TTL, including one that clears it, and is never reset.
• So if thread A declared the table, and thread B later saves a different TTL through its own declaration, A's reload keeps A's value. If A owns the cleanup scan, records are reclaimed on A's value, not the saved one.

This is the documented contract from #3924 ("A reload keeps a thread's own TTL", resources/DESIGN.md). It holds in the usual deployment, where every worker runs the same schema and re-declares on restart. It diverges when declarations differ by thread: a defineTable/table() call made from a request handler, or an isolated application's tables.

Expected

Decide whether a newer saved value from another thread's declaration should supersede this thread's older declaration (for example, a revision stamp on the catalog row that adoption compares), while still keeping a TTL application code set at runtime.

Found by review of the table TTL configuration bundle (#3934, #3935); pre-existing.

Review-Deferral: 62e841f508e3e609 severity=minor category=correctness

_{🤖 Generated by Claude Opus 5.5 (Claude Code); posted via @kriszyp.}