emrg: the llm.jsonl rotation leaves a stray backup generation when the numbering has a gap #2702

_rotate_llm_log (emrg/session.py) removes the backup generations numbered at or above _LLM_LOG_BACKUP_COUNT by counting up from _LLM_LOG_BACKUP_COUNT + 1 and stopping at the first name that does not exist. The comment above that loop states two things about the result: the set is "the live log plus _LLM_LOG_BACKUP_COUNT backups and no more", and "every generation numbered at or above the count goes".

The second claim is false whenever the numbering has a gap.

What is observed

Driving the real function, in a temporary directory, from a session holding the live log plus .1, .2 and .4 — with .3 absent:

The .4 generation survives because the sweep reaches .3, finds nothing, and stops there. The set stays at three backups for the rest of that session's life, contradicting both the comment and the declared count.

Why it matters

The gap is not imaginary: a .4 can be left behind by a session directory that was restored, copied or edited by hand. The numbering is contiguous only because this code writes it that way, and a claim the code does not keep is the one shape a later reader cannot detect — the count they check against is the constant, which says 2.

Expected

After one rotation from that state, the set is the live log plus _LLM_LOG_BACKUP_COUNT backups, and those backups are the two newest generations.

Acceptance

1. A test drives the real _rotate_llm_log from each of these states, under tmp_path, and asserts the survivors by content — each backup's first line names the generation that wrote it, so the assertion separates "the right two" from "one too many", which a file count cannot: live; live .1; live .1 .2; live .1 .2 .3; live .1 .2 .3 .4 .5; and the gap live .1 .2 .4.
2. After one rotation, the gap state ends holding the live log plus two backups, and those two are the newest.
3. The three carriers still agree on the count: _LLM_LOG_BACKUP_COUNT (emrg/session.py), the append_llm docstring's "up to 2 backup files", and system.j2's "rotated with two backups".

Nothing under tests/ names _rotate_llm_log or _LLM_LOG_BACKUP_COUNT today, so this behaviour is unmeasured: the gap above is the state that reveals it, and the test in item 1 is the reading that was missing.