a self-update finishing at a logrotate boundary is reported FAILED after the full timeout #14804

A self-update finishing at a logrotate boundary is reported FAILED after an hour

autobot-slm-backend/api/code_sync.py:5573-5578

When _completion_is_from_a_rotated_log() is true, the watch declines to treat that
poll's completion as its own and keeps waiting. That is the right call in general —
the live log's mtime dates the truncation rather than a play, so the reading cannot
be trusted.

The gap is that the condition can become permanent for the remainder of the
watch. logrotate uses copytruncate and the running ansible process holds the
log fd open, so if the play's recap write lands right at the rotation boundary, the
recap ends up only in the rotated .1 file and the live log stays truncated — the
process has already exited, so nothing will ever write to it again for that run.

Every subsequent poll then sees the same rotated-source signal and keeps waiting. A
genuinely successful self-update resolves only when
_SELF_UPDATE_WATCH_TIMEOUT_SECONDS (3600s default) expires, and is then reported
FAILED — a false negative on a deployment that actually worked.

Severity

Low. It is bounded — the deadline check runs unconditionally every iteration, so
there is no infinite hang — and the window is narrow, since rotation is daily
against a watch of at most an hour. But the outcome is wrong rather than merely
slow: an operator sees a failed self-update that succeeded, and the fleet stage does
not run.

Suggested fix

When the rotated source is detected, use the rotated file's own mtime as a secondary
freshness signal rather than deferring unconditionally: .1's mtime dates the actual
recap capture, so comparing it against since distinguishes "our recap, in the
rotated file" from "a stale reading we must not trust".

Acceptance criteria

• A play whose recap lands only in the rotated file still resolves the stage
  when that file's mtime is newer than stage.started_at
• A genuinely stale rotated reading is still refused
• A test covers both, and the refusing case fails if the guard is removed
• The timeout still bounds the wait in every case

Found reviewing #14685, which is otherwise approved. Not introduced there — the
rotated-log guard is what makes the false negative reachable, and the guard itself
is correct and worth keeping.