testing/cross_backend/token_lifetime.ts

Cross-backend parity suite for the API token lifetime axis of account_token_create — the round-trip that keeps a one-sided landing impossible.

Why this suite exists

The action-manifest parity gate captures {method, side_effects, auth} and no param schemas, while the TS spine validates params against a Zod strictObject and the Rust spine hand-parses with params.get(...). So a spine that silently ignored the lifetime field would answer the same mint request with a 200 and an eternal token — same method, same status, nothing red anywhere. The forcing function has to observe the *stored* state: mint with a TTL, then read expires_at back off the wire.

What it pins

• A TTL mint stores a bounded expiry — account_token_create with {kind:'ttl', days} returns a non-null expires_at (create output *and* account_token_list), landing within a generous window around now + days. A spine that dropped the field returns null and fails.
• An eternal mint stores NULL — the control: {kind:'eternal'} yields expires_at: null on both reads.
• An omitted lifetime is refused — lifetime is required; a mint without it must 400 invalid_params on both spines. This is the direct pin on the silently-ignoring-unknown-shapes hazard.
• Out-of-range days are refused — days: 0 400s identically, so the two hand-rolled bounds checks can't drift.

$lib-free by contract (relative specifiers only), like the sibling cross-backend suites. Runs both legs — in-process (gro test) and cross-process — through the shared {setup_test} protocol.