A schema TTL of 0 leaves an application-set TTL in place, like an omitted one #4253

Summary

A schema that sets a table TTL to 0 (@table(expiration: 0), or defineTable(..., { expiration: 0 })) leaves a TTL that application code set at runtime (for example through sourcedFrom(source, { expiration })) in place, exactly as a schema that omits expiration does. Someone who writes expiration: 0 explicitly may expect it to turn expiration off on every thread.

Mechanism

• @table and defineTable pass null for an omitted expiration/eviction (resources/graphql.ts, resources/defineTable.ts).
• declareTable normalizes null to 0 through ttlSecondsOf before it calls setTTLExpiration({ ..., fromSchema: true }) (resources/databases.ts), so the setter cannot tell an explicit 0 from an omitted value.
• setTTLExpiration keeps the part of the TTL application code set when a schema declares no TTL (applicationTtl in resources/Table.ts), and treats 0 as "no TTL".

Before #4250, an explicit 0 never reached the setter at all, so the application TTL survived then too. This is not a regression. #4250 documents the current behavior in docs/reference/database/schema.md.

Decide

Either keep 0 meaning "declares none" (the current, documented behavior), or carry an "explicitly set" flag from graphql and defineTable through declareTable, so that an explicit 0 clears an application-set TTL as well.

Found by review of #4250 (QA finding F-1241).

Review-Deferral: b8406dd465c94218 severity=minor category=correctness

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