PR title: fix(logs): only report rotation when the log file actually shrank

Summary

• Problem: openclaw logs --follow prints Log cursor reset (file rotated). to stderr whenever the gateway log grows faster than --max-bytes between polls, even though no rotation has occurred — the cursor is still valid and the tail was just truncated to fit the byte budget.
• Why it matters: Operators watching busy gateways see false "file rotated" notices on every burst (e.g. during a noisy startup or while a chatty channel pumps logs). The accompanying Log tail truncated (increase --max-bytes). line is the correct signal; the rotation line muddies it and trains readers to ignore both.
• What changed: In src/logging/log-tail.ts::readLogSlice, only set reset = true in the true rotation case (cursor > size — the file shrank below the previous cursor). The fast-growth branch (size - start > maxBytes) now sets truncated = true only, since the cursor it returned remains contiguous with what the caller saw last poll.
• What did NOT change (scope boundary): The LogTailPayload shape, the rotation-case behavior, the Log tail truncated message, and the byte-budget arithmetic are all unchanged. No CLI strings, schema, or downstream consumers were modified — src/logging/diagnostic-support-export.ts and src/cli/logs-cli.ts continue to work with the same fields.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration (logging is shared infra)
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX (stderr notice text)
• CI/CD / infra

Linked Issue/PR

• No existing issue. Found while reading sibling cron handler code around [Bug]: cron add / cron edit with invalid --cron expression logs gateway error and returns UNAVAILABLE instead of INVALID_REQUEST (raw croner TypeError/RangeError leaks to CLI + log) #74066.
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: readLogSlice conflated two situations into a single reset flag:
  1. cursor > size — the previously-returned cursor is past EOF; the file was rotated/truncated, so the cursor is meaningless and we must restart from the new tail.
  2. size - start > maxBytes — the file grew faster than the per-poll byte budget; the cursor is still valid, we just can't read everything that was appended in one poll.
     Only case (1) is a real reset/rotation. Case (2) was incorrectly being flagged as "rotated" because both branches set reset = true.
• Missing detection / guardrail: log-tail.test.ts only covered the redaction path; nothing pinned the meaning of reset vs truncated.
• Contributing context: The CLI side (src/cli/logs-cli.ts:402) hard-codes Log cursor reset (file rotated). for payload.reset, so the conflation surfaced as a misleading user-visible string rather than a silent boolean.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/logging/log-tail.test.ts
• Scenarios the test locks in:
  1. File grows by >> maxBytes between two polls with the same valid cursor → truncated: true, reset: false, lines returned.
  2. File shrinks below the previous cursor (real rotation) → reset: true.
• Why this is the smallest reliable guardrail: the bug is at the readLogSlice boundary; both scenarios can be exercised end-to-end against a real temp log file using the existing setLoggerOverride test seam.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

openclaw logs --follow (and JSON-mode --json) no longer emits the Log cursor reset (file rotated). notice during high-throughput writes. The existing Log tail truncated (increase --max-bytes). notice still fires in that case, which is the actionable signal. The notice still fires correctly when the log is genuinely rotated/truncated.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• N/A

Repro + Verification

Environment

• OS: Ubuntu 24.04 (WSL) / Windows 11 host
• Runtime/container: Node 22 (pnpm dev)
• Model/provider: N/A
• Integration/channel (if any): N/A — gateway logs only
• Relevant config (redacted): default loggerSettings

Steps (to reproduce the original misleading notice on main)

1. Start a gateway with anything that writes a steady stream of log lines (e.g. a chatty channel or openclaw status --watch against a busy gateway).
2. In another terminal: openclaw logs --follow --max-bytes 4000.
3. Wait for a write burst that exceeds 4 KB between two polls.

Expected

Only Log tail truncated (increase --max-bytes). is printed to stderr while the burst is being caught up.

Actual (before this PR)

Both Log tail truncated (increase --max-bytes). and Log cursor reset (file rotated). are printed, even though the file was never rotated.

After this PR

Only the truthful Log tail truncated notice is printed during fast growth. The rotation notice still fires when the file is actually rotated/truncated (covered by the second new test).

Evidence

• Failing test/log before + passing after (see new tests in src/logging/log-tail.test.ts)
• Trace/log snippets (see "Repro + Verification")
• Screenshot/recording
• Perf numbers (if relevant)

Local verification:

# Targeted unit lane
pnpm test src/logging/log-tail.test.ts
# Expect: 3 tests pass (1 existing + 2 new)

Note: I was unable to run the full repository test sweep locally (the dev environment is on a WSL/Windows-mounted filesystem that pnpm refuses to install into with ERR_PNPM_EACCES). The fix is a 5-line local change inside readLogSlice with no schema, no public-API, and no other call-site impact, and the new tests exercise the exact two paths affected. CI in this repo runs the full lane.

Human Verification (required)

• Verified scenarios: fast file growth between polls → no rotation message; real rotation (file shrunk) → rotation message still emitted.
• Edge cases checked: initial poll with no cursor still uses start = max(0, size - maxBytes) and reports truncated only (unchanged); empty file still returns cursor: size, lines: [] (unchanged); cursor inside [start, size] window with size - start <= maxBytes is unchanged.
• What I did NOT verify: live CLI output against a running daemon during a real burst (will rely on CI + reviewer spot-check).

Review Conversations

• I will reply to or resolve every bot review conversation I address in this PR.
• I will leave unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• N/A

Risks and Mitigations

• Risk: a downstream consumer relies on reset === true to mean "skipped some lines" rather than "the cursor is no longer meaningful".
  • Mitigation: I grepped the repo for payload.reset / LogTailPayload. The only consumers are src/cli/logs-cli.ts (renders the user-visible string this PR is correcting) and src/logging/diagnostic-support-export.ts::sanitizeLogTail (passes the boolean through verbatim into the support bundle). Both are display-only; neither uses reset to decide whether lines were skipped — they use the existing truncated flag for that.

AI/Vibe-Coded PRs Welcome! 🤖

• AI-assisted PR. Drafted with help from Claude (Opus 4.7) via the GitHub Copilot CLI agent harness.
• Degree of testing: lightly tested — new unit tests added; full repo lane not run locally (see note above).
• Prompts/session logs: available on request.
• I understand exactly what the code does (5-line semantic narrowing of when reset is asserted in readLogSlice).
• codex review --base origin/main not run locally (no Codex access in this environment); happy to address Codex bot comments after the PR opens.
• Will resolve bot review conversations after addressing them.