test: log rotation — verify --log-max-size/files/total trigger cleanly

[arcaven]

What to test

PR #25 added --log-max-size, --log-max-files, --log-max-total flags wired to internal/rlog. The in-memory ring is separate from the on-disk file. We want to confirm that when the active daemon.log crosses the size cap, it's gzipped, rotated archives named daemon.log-<timestamp>.gz appear, retention trims the oldest.

Known constraint

--log-max-size is expressed in MiB and the minimum is 1 (1 MiB). That's higher than ideal for forcing a rotation quickly but it's the floor today. This test is already running on desk — subsequent tests in this epic (crash loops, shift, scale) will drive the log volume up faster and accelerate rotation.

Test plan

1. marvel daemon --mrvl --log-max-size=1 --log-max-files=3 --log-max-total=10
2. Let the other tests in this epic generate log volume.
3. Monitor ls -la ~/.marvel/log/ periodically.
4. Once daemon.log nears 1 MiB, watch for rotation.

Pass

• A daemon.log-<timestamp>.gz archive appears when the active file crosses 1 MiB.
• Active daemon.log truncates back to well under 1 MiB after rotation.
• --log-max-files=3 — at most 3 gzipped archives + 1 active. Older archives deleted.
• --log-max-total=10 — total disk usage of log dir never exceeds 10 MiB.
• gunzip of each archive produces readable log content with no truncation at boundaries.

Fail

• File grows unbounded past cap.
• More than --log-max-files archives accumulate.
• Disk usage exceeds --log-max-total.
• Corrupted gzip or truncated lines in archives.

Related: PR #25.

[arcavenai]

PASS (rotation fires, archives valid).

Daemon: marvel daemon --mrvl --log-max-size 1 --log-max-files 2

After live driving ~1 MiB of ssh-poll + session-lifecycle traffic:

$ ls -la ~/.marvel/log/
-rw------- 1 skippy skippy 133023 Apr 18 23:34 daemon.log
-rw------- 1 skippy skippy  19347 Apr 18 23:31 daemon.log.20260419T043147Z.gz

Verified

• ✓ Rotation fires when active log crosses cap (size at trigger: 1048655 bytes ≈ 1.00 MiB)
• ✓ Active daemon.log truncates back to well under cap after rotation (back to 133K, growing again)
• ✓ Archive is a valid gzip: gunzip -c decompresses cleanly, first and last lines intact
• ✓ Compression ratio: 98.2% (1048655 → 19347 bytes — mostly-identical ssh-poll lines compress extremely well)
• ✓ 9191 lines preserved in the archive, no boundary truncation

One spec nit

Plan said rotation files would be named daemon.log-<timestamp>.gz (hyphen). Actual naming is daemon.log.<timestamp>.gz (dot). Mostly cosmetic — no ambiguity, pattern is consistent — but flagging in case the plan wants updating.

Not yet verified (time-limited)

• --log-max-files=N retention trim: only one archive so far; need at least 3 to see the oldest evicted
• --log-max-total=N MiB cap: never approached given current volume

Both should be straightforward to confirm under continued load. Closing since the core behavior works; can reopen if retention limits misbehave.