fix: initialize log_written from file size to prevent 2x cap drift

[ricardovfreixo]

Summary

The on-disk session log can grow to twice the configured -C cap before rotation kicks in.

Root cause

log_written tracks bytes written since the last rotation, not the actual file size. After open_log(), the file can already contain up to log_max_size bytes (trimmed by rotate_log()), but log_written is initialized to 0. Rotation only triggers when log_written >= log_max_size, so another full log_max_size of data is appended before the check fires.

Timeline with -C 512k:

open_log()
  → rotate_log() trims file to 512KB
  → log_written = 0          ← bug: should reflect current file size

... 512KB of pty output ...

  → log_written = 512KB
  → file is now 1MB (2x cap)  ← rotation finally triggers
  → rotate_log() trims back to 512KB

Fix

Initialize log_written from the fd position after rotate_log() in open_log(), so the counter reflects the actual file size from the start:

log_fd = fd;
rotate_log();
log_written = (size_t)lseek(log_fd, 0, SEEK_CUR);

Single line change, no new syscall overhead (piggybacks on the position rotate_log() already established via its final lseek(log_fd, 0, SEEK_END)).

Test plan

• Start a session with a small cap: atch new test -C 64k -- sh -c 'cat /dev/urandom | base64'
• Let it run until well past 64KB of output, then detach
• Check file size: ls -la ~/.cache/atch/test.log — should be at most ~64KB (plus one write batch), not ~128KB
• Reattach, generate more output, detach again — file should stay near the cap
• Verify session replay still works: atch test shows recent output, not truncated mid-sequence
• Build with make clean && make — no new warnings

[arthurpro]

thanks for submitting your PR! 👍
yes, I know about it and I've been thinking about it. I kinda left it for later.
my original motivation to allow it grow was to relax log rotation.
if we enforce hard limit of the log size and it reaches the limit then it will start constantly rotating the log when new data arrives which may create unnecessary IO on disk because it will have to replace entire file on disk every time rotation triggers.
in current scenario it only happens once in a while when it reaches 2x log size which is much more efficient in my opinion.
I'm still open to your solution. I need to take a closer look.

[ricardovfreixo]

We can have both. If you don't set any cap, it assumes the 2x log size, but if you cap it, it respects the cap. I think using both we can cover all the possible cases