opus-4-7 independent review found three issues missed by earlier
review rounds:

P1 — _persistPathOverride was still module-local
  Despite the Codex thread reply claiming the override moved into the
  shared persistState global, it was still a module-local 'let'. Tests
  passed by accident: in-memory dedupe shared via persistState.entries,
  but disk side effects from re-imported module copies leaked into
  STATE_DIR instead of the per-test temp dir. Moved into
  PersistState.persistPathOverride on the global singleton.

P1 — CWE-59 symlink-follow on tmpPath (Aisle medium #2, unaddressed)
  tmpPath was ${filePath}.${process.pid}.tmp + default 'w' flag. A
  predictable name combined with a truncating O_CREAT would let an
  attacker who can write to the state dir pre-create a symlink at the
  tmp path pointing to e.g. /etc/passwd, and our write would follow it.
  Now uses randomUUID() for the name AND flag 'wx' (O_CREAT | O_EXCL)
  so any existing entry — file or symlink — fails the write safely.

P2 — hydration ignored MAX_ENTRIES (Aisle medium #1)
  The 4 MB file-size cap permits ~250K entries through, blowing past
  the 5K in-memory MAX_ENTRIES on first load. Now collects valid
  candidates first, sorts DESC by ts, and slices to MAX_ENTRIES before
  inserting into the dedupe cache. Bounds memory regardless of file
  size up to MAX_PERSIST_FILE_BYTES.

Tests: 26/26 pass (3 new tests covering each fix).

Architectural note (per opus review): Land standalone. Don't migrate
to plugin-sdk/persistent-dedupe — its hasRecent reads JSON on every
miss, adding ~2-10ms to every Slack message in a thread the bot
hasn't replied to (the dominant path for hasSlackThreadParticipation
on the message-dispatch hot path). Warm-cache + debounced-write is
correct here. Don't block on openclaw#70626.

gpt-5.5 independent review (running in parallel, no shared context with
opus) confirmed both opus P1s and opus P2-A. It also surfaced three
additional findings worth landing in this PR:

P2-B — Duplicated persist logic between schedulePersist callback and
  _flushPersist. Maintenance trap: any future hardening had to be
  mirrored in two places. Extracted into a shared persistToDisk()
  function called from both. Single source of truth for prune/cap/
  serialize/atomic-write.

P2-C / P3-C — Future timestamps from a crafted persist file (or a
  backwards system-clock jump) survive forever. The previous guard
  was 'now - ts < TTL_MS' which trivially holds for ts > now.
  Added 'ts > 0 && ts <= now' to the hydration filter so:
   * future-near (now + 60s)        -> rejected
   * future-far (MAX_SAFE_INTEGER)  -> rejected
   * zero / negative                -> rejected
   * monotonic-clock-skew tolerance -> small backwards jumps still
     reject the affected entries on next hydrate; corrected on next
     write cycle. Trade-off vs. monotonic-clock complexity is
     intentional.

P2-D — mkdirSync called with no mode flag -> directory inherits umask
  (often 0o755 — group/other readable). Now passes mode 0o700 to
  match the SDK helper and complement the 0o600 file mode. Multi-tenant
  hosts can no longer enumerate or symlink-squat the persist directory.

P3-B — Iteration-order inversion after over-capacity slice. When >
  MAX_ENTRIES candidates were sorted DESC + sliced, the resulting
  Map insertion order was ts-DESC, but the eviction loop in
  recordSlackThreadParticipation assumes Map insertion order = ts-ASC
  (oldest first). Without this fix, the first post-hydration eviction
  drops the NEWEST entry instead of the oldest. Added an ASC re-sort
  on both hydration and serialize paths so insertion order always
  matches recency.

Tests: 29/29 pass (4 new tests covering each finding).

P3-A (TOCTOU stat->read race) deferred to follow-up: low-impact given
the 4 MB file cap already bounds the read, and a fix requires
fs.openSync + fstatSync + readSync changes that don't align with the
current stat-then-read structure. Worth its own PR.

Per gpt-5.5 architectural call: keep this PR standalone; converge
with plugin-sdk/persistent-keyed-store (openclaw#70626) as a follow-up after
this lands. The sync->async migration is straightforward (3 call sites,
all in async contexts) but should be coordinated with maintainers.

…icipation-persist

# Conflicts:
#	extensions/slack/api.ts
#	extensions/slack/src/sent-thread-cache.ts