Make @expiresAt attribute authoritative over the table expiration default

[kriszyp]

Fixes #1810. Reported internally (Jeff Darnton): a record-level @expiresAt field can only shorten-by-eviction, never extend past the table @table(expiration:) default.

Summary

The @expiresAt schema attribute's value was never fed into the stored expiry metadata that governs read-hiding and the cleanup sweep — it only armed a separate index-pruning sweep (runRecordExpirationEviction) that removes records already past due. So a far-future field value was ignored by both read-hiding and the table sweep, and could never extend past the table default. (And per #1481 that pruning sweep is LMDB-only, so on RocksDB the field enforced nothing at all.)

This resolves the stored expiresAt in the _writeUpdate commit path as:

options.expiresAt ?? context.expiresAt ?? (record @expiresAt field, if finite and >= 0) ?? table default

enforcing the invariant that the stored expiry metadata reflects the record's effective expiration. Because read-hiding and the getRange-based cleanup sweep (shouldEvict) are engine-agnostic, this also enforces field-derived expiry on RocksDB for new writes — addressing the correctness half of #1481 without depending on the LMDB-only pruning sweep (that sweep's index.getValues→getRange fix, which also covers pre-existing records, remains tracked in #1481).

Where to look

• resources/Table.ts — the new field-resolution block sits after recordToStore is merged, so it reads back exactly what the pruning sweep later sees. Negative field values are guarded (Number.isFinite(x) && x >= 0) because a negative epoch collides with the -1 "no expiration" metadata sentinel.
• Precedence intentionally keeps options.expiresAt / context.expiresAt (the documented runtime override) ahead of the field.

Deliberate scope boundary (please sanity-check)

• Direct writes only. Cache/source fills persist via a separate recordUpdater path and derive expiry from sourceContext.expiresAt (source freshness / table default), not the field. For a caching table the source's freshness signal is the authoritative TTL, so I left it as-is and documented it (Document the @expiresAt schema directive documentation#585, DESIGN.md). Cross-model review agreed this is a correct boundary, not a gap — flagging so a human can confirm the product intent.
• Replicated writes carry options.expiresAt = event.expiresAt, so the receiver honors the origin's computed expiry rather than re-resolving the field. Correct-by-design for convergence; this PR doesn't touch that path.

Coverage notes (from the cross-model review)

• Unit tests cover direct put/patch on RocksDB (unitTests/resources/expiresAtAttribute.test.js): extend, shorten, table-default fallback, options override, patch-preserves, negative-value guard, and end-to-end read-hiding on a field-only table. LMDB metadata stamping is engine-agnostic but untested here (RocksDB is the @expiresAt per-record TTL never evicts on RocksDB (default engine) — index.getValues() is LMDB-only #1481 primary target).

Docs companion: HarperFast/documentation#585.

Generated by KrAIs (Claude Opus 4.8). Reviewed cross-model (Codex + Gemini + Harper-domain adjudication); no blockers.

[gemini-code-assist]

Code Review

This pull request updates the record-level TTL evaluation logic to make the schema-defined @expiresAt attribute authoritative over the table-level expiration default, allowing it to both extend and shorten the expiration time. It also adds comprehensive unit tests to verify this behavior under various scenarios. The review feedback points out a potential issue with using Number() directly for coercion, as values like booleans or empty strings can be coerced to 0 (causing immediate expiration) and ISO strings are ignored, and suggests a more robust parsing implementation.

[claude]

Reviewed; no blockers found.