Catalog-loaded table TTL: eviction-only tables never arm a scan, negative eviction accepted on create #3935

Summary

Loose ends in how a catalog-loaded table arms and validates its TTL, found while reviewing #3924 and harper-pro#1233. Each matches the existing fresh-load behavior; none blocks those PRs.

• Eviction-only tables never arm a cleanup scan on a thread that loads them. makeTable calls setTTLExpiration only when expirationMs is non-zero, and _adoptCatalogExpiration mirrors it. A node that received the table from a peer, or restarted, keeps expired rows on disk until a read or an expiresAt write arms the scan.
• A table created from a peer's definition scans daily on its creating thread, like every catalog load (#2831 point 2), instead of (expiration + eviction) / 4.
• A negative eviction is accepted on the create path (only expiration is checked in setTTLExpiration), while a re-declaration now rejects it.
• setTTLExpiration assigns expirationMs/evictionMs/recordScanInterval before its negative check throws, leaving the rejected value live (application path only).
• catalogExpiration reads the named primary row first while catalogCreatedTime reads the bare row first; on a pre-5.x catalog with both rows, peers could get the two values from different rows.
• catalogExpiration has no production consumer inside core (its consumer is harper-pro replication).

Review-Deferral: a7ae77d58bfe4304 severity=minor category=reliability
Review-Deferral: f55fe88ffc1014eb severity=minor category=reliability
Review-Deferral: 728bc90858dbfd00 severity=minor category=correctness
Review-Deferral: 0d30073861d5b16a severity=nit category=correctness
Review-Deferral: 1e8966db27e5b4b9 severity=nit category=maintainability
Review-Deferral: b311fe732b6836fa severity=nit category=maintainability
Review-Deferral: 7ccf326b0873d703 severity=minor category=reliability
Review-Deferral: 21546721800669c0 severity=minor category=reliability

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