Copilot Chat stays unavailable after a lookup lands in the gap of a log rotation #3109

Follow-up from #3086 (Copilot Chat across log rotation).

How Copilot 1.0.105 rotates (measured by driving its own native logger, runnerCreateFileLogger in runtime.node): at about 10 MiB it renames the copies up (.1.log to .2.log and so on, keeping four), writes the new copy to .1.log.rotation-staging, renames it to .1.log and then empties the open log in place. Between the rename of .1.log and the new one landing, there is no .1.log at all.

What happens. A lookup that lands in that gap treats it as a rotation, finds no copy that carries on from the bytes it read, and stores copilot_log_rewritten. Chat then stays unavailable, falling back to the terminal, until Copilot registers a session again, even after the new .1.log is in place. This is deliberate in #3086: treating the gap as "not a rotation" let a reader keep a session that the copies had already left behind (reproduced: two rotations between lookups returned A, A, A instead of A, unavailable, B).

How often. With Copilot's real logger writing and rotating six times while the reader looked up the session continuously, 3 of 10 runs ended unavailable this way; none showed a wrong session.

Possible fix. When the newest copy is missing after a checkpoint that saw one, answer unavailable for that lookup only, without storing anything. When .1.log is back, compare it with the stored stamp and follow the rotation from the earlier checkpoint as usual. Keep the two-rotation test (never shows a session left in the copies when a lookup lands inside rotation 2) and add one for the gap recovering.