[BUG] store.ts writes created_at in mixed units (seconds vs milliseconds) — breaks time-based queries and cleanup

[ryangu00]

Bug Description

memory_session table stores created_at and last_accessed timestamps in mixed units — some rows use seconds (Unix epoch), others use milliseconds. This breaks all time-based queries, cleanup, and backup operations.

Reproduction

1. Run memory-lancedb-pro with autoCapture: true over several days
2. Some entries get created_at in seconds (e.g., 1774509333), others in milliseconds (e.g., 1774509333015)
3. Time-based filtering fails — pd.to_datetime() with unit="ms" renders seconds-era rows as 1970-01-21

Data Evidence

Total rows: 73,291
Seconds unit (< 2e9): 1,604 rows  ← migrated/older data
Milliseconds unit (≥ 2e9): 71,687 rows  ← newer data

After fixing manually (×1000 for seconds rows), the data spans 2026-03-07 → 2026-04-22 as expected.

Root Cause

Likely inconsistency in src/store.ts:

• Some code paths use Date.now() (milliseconds)
• Others use Math.floor(Date.now() / 1000) or receive seconds from migration/import paths
• No unit validation on write

Impact

• Time-based delete-bulk --before CLI command produces incorrect results
• created_at and last_accessed are unreliable for lifecycle decay calculations
• Smart-extractor BigInt errors when JS tries arithmetic on mixed-unit int64 values (related to [BUG] Smart-extractor skips [cases] category due to misleading BigInt prompt guidance #640)
• Backup path resolution may fail when reading these fields (backup failed: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of Buffer or URL. Received undefined #682 may be related)

Suggested Fix

1. store.ts: Add a normalizeTimestamp() utility that detects unit:

   function normalizeTimestamp(ts: number): number {
     // Values < 1e12 are likely seconds — convert to ms
     return ts < 1e12 ? ts * 1000 : ts;
   }

2. Apply on every write to created_at and last_accessed
3. Add a migration in openclaw memory-pro upgrade to fix existing rows
4. Add unit tests asserting all timestamps are in milliseconds after write

Environment

• Plugin: memory-lancedb-pro 1.1.0-beta.9
• LanceDB: memory_session table
• OpenClaw: 2026.4.21

[AliceLJY]

Confirmed as a real data-integrity bug. The important part is to normalize timestamp units at the store boundary, not only in query code.

Suggested fix scope:

1. Add a small normalizeTimestamp() helper and apply it to every created_at / last_accessed write path, including migration/import/upgrade paths.
2. Add an upgrade step that converts existing memory_session rows where timestamp values are clearly seconds (< 1e12) to milliseconds, with a dry-run/count output before mutation.
3. Add regression tests for both Date.now() millisecond input and legacy seconds input.

I would keep this separate from #682. A bad timestamp corpus can expose backup/cleanup bugs, but the backup path guard and timestamp normalization are different fixes.