Summary

Fixes openclaw#63892. After the first compaction, `entry.totalTokensFresh` is set to `true` by `incrementRunCompactionCount`. On subsequent runs, `runPreflightCompactionIfNeeded` unconditionally short-circuits at `src/auto-reply/reply/agent-runner-memory.ts:379` because `shouldUseTranscriptFallback` is `false`. The stale-tokens path below (which is what runs the actual threshold check) is never reached, so proactive compaction never re-fires. Overflow-retry recovery still worked because it runs through a separate path in `src/auto-reply/reply/pi-embedded-runner/run.ts` that catches `isLikelyContextOverflowError` directly, bypassing the preflight gate entirely.

• Problem: Proactive compaction never re-fires after the first checkpoint on long-lived sessions. Users only see compaction when a request actually overflows the context window.
• Why it matters: On 100k+ sessions (reported against GLM-5.1:cloud, observed against Anthropic + Gemini providers in the issue thread) this turns every long conversation into an eventual overflow-and-retry instead of a smooth proactive checkpoint.
• What changed: The preflight fast-path early return now also requires `freshPersistedTokens < preflightThreshold`. When fresh tokens have grown back above the threshold, the guard falls through and the existing `shouldRunPreflightCompaction` path runs normally. The duplicate `threshold` local was consolidated onto the new `preflightThreshold` that the guard uses, so the `logVerbose` output is unchanged.
• What did NOT change (scope boundary): No changes to `shouldRunPreflightCompaction`, `incrementRunCompactionCount`, the overflow-retry path, or the stale-tokens transcript-fallback branch. No config/schema/public SDK surface touched.

Change Type

• Bug fix

Scope

• Memory / storage
• Agents / orchestration (preflight compaction)

Verification

• `pnpm test src/auto-reply/reply/agent-runner-memory.test.ts` — 5/5 passing
• `pnpm check` — clean (tsgo, lint, all policy gates)
• `pnpm build` — clean
• Regression test covers both directions:
  • `totalTokensFresh: true` + tokens above threshold → `compactEmbeddedPiSession` is called (proactive compaction fires — this is the bug fix).
  • `totalTokensFresh: true` + tokens below threshold → fast-path early return still fires unchanged.

I also verified the equivalent gate on the compiled dist of v2026.4.9 on a long-running gateway against GLM-5.1:cloud (`contextWindowTokens` ≈ 200k, `reserveTokensFloor` 40k, `softThresholdTokens` 25k). Before the patch: zero proactive checkpoints after the first, overflow-retry checkpoints only. After the patch: proactive checkpoints fire on every subsequent cycle as expected.

Credit

The root cause analysis, exact file/line pointers, and the fix direction are all @martingarramon's from the issue thread. My earlier hypothesis about `compactionCount` latching was wrong — thanks for the correction. @mjamiv independently confirmed the repro on v2026.4.9, which is what motivated digging past the first hypothesis.

AI-assisted disclosure

This PR was written with AI assistance (Claude). I (the submitter) read and understand the change, verified the fix against the live compiled runtime before writing the source patch, and wrote the regression tests to directly exercise the `totalTokensFresh === true` re-fire case.

Fixes openclaw#63892