Record dates on the tokens, bases, review and rules pages follow the reader's time zone

[Maya-Kid]

The tokens, bases, review and rules pages date record moments by slicing the ISO string, which gives the UTC day, not the reader's.

Problem

East of UTC, early-morning records show the previous day; west of UTC, late-evening ones show the next day.

On dev 15fd7d5, a reader in Shanghai creates a 30-day token at 07:30 on 16 October (2026-10-15T23:30Z). The tokens page lists it as created 2026-10-15 and expiring 2026-11-14, though it works until 07:30 on 15 November.

The bases page (date joined), review (merges, agent decisions, precedents, decision history) and rule history slice the same way. ui/index.tsx documents localDate for moments; EntityHistory already stopped slicing for this reason.

Change

• Those record moments go through localDate; the ymd slicing helpers in Tokens.tsx and MyKbs.tsx go.
• World-time fields (valid_from, valid_to) still slice; they are calendar dates.

Verification

accountRecordDates.test.ts renders the real pages with TZ=Asia/Shanghai; both tests fail on dev:

• Tokens: all five dates (created, last used, expiry; an old token's created and revoked) are a day early.
• Bases: "Added by Alice" and "Joined" read 2026-10-15, not 2026-10-16.

Review and rules get the same swap, on TIMESTAMPTZ fields, without tests of their own: merges, decision history, precedents and rule history render only after a click, which this DOM-less suite cannot make; the agent rows repeat the localDate call pinned above.

Linux x86_64 container, node 20.20.2, pnpm 10.2.1, commit 0d6e2a5: pnpm test 40 files, 283 tests passed; pnpm build passes.

Limits

• Library (last sync, run start, missing since) and Mappings (changed at) still print UTC clock times; localDateTime fits them, in a separate change.
• Group knowledge bases named owner/name in the pickers #1250 also edits Tokens.tsx and MyKbs.tsx; the two merge cleanly against its head 3be9b1d. Govern conflicts in the typed graph and preserve human decisions #1131 adds another precedent line that slices p.at.

[WaylandYang]

Thank you. Using the existing localDate and dropping the two ymd slicers is the right fix, and keeping valid_from/valid_to as slices respects the rule in ui/index.tsx that calendar dates have no time zone. The Shanghai fixture shows the bug clearly. A small note: the Kb literal in the test could be cast from { id, name }, since the page reads nothing else from it, and #1131 adds another p.at.slice(0, 10) in Review.tsx that should use localDate once both have landed. Merging.