fix: process log retention never reached files with no in-memory record

[dvystrcil]

Problem

_cleanup_expired()'s log-file deletion only runs when a finished log file also has a matching in-memory BackgroundProcess record:

for process_id in expired:
    bp = _processes.pop(process_id)
    if bp.log_path and bp.finished_at and now - bp.finished_at > PROCESS_LOG_RETENTION:
        os.remove(bp.log_path)

_processes is an in-memory dict that resets to empty on every process restart. The JSONL log files under LOG_DIR/processes/ live on disk (frequently a persistent volume in containerized deployments) and survive restarts. So any log file older than the last restart is permanently unreachable by this cleanup path, regardless of age -- the in-memory record it would need to be found via is simply gone.

I ran into this concretely: a long-forgotten process log (months old) was still sitting on disk, and it contained the plaintext output of a command that had echoed a secret to stdout. PROCESS_LOG_RETENTION defaults to 7 days, but nothing was actually enforcing that once the server had restarted even once since that log was written.

Fix

_cleanup_expired() now also sweeps the log directory by file mtime directly (open_terminal/utils/log.py's new sweep_expired_log_files), independent of any in-memory record. Since _cleanup_expired() runs on every process-status-check request (/execute list, individual status polls), the actual directory scan is rate-limited to once per 5 minutes (sweep_expired_log_files_rate_limited) to avoid adding a full os.listdir() on every request under active polling.

Kept the fix minimal and reactive (piggybacking on the existing _cleanup_expired() call sites) rather than introducing new background-task/scheduling infrastructure, since none currently exists in this codebase.

Testing

No test harness exists in this repo currently, so verified manually and end-to-end:

• Unit-level: confirmed sweep_expired_log_files deletes only .jsonl files older than the retention window, leaves recent and non-.jsonl files alone, and the rate-limited wrapper correctly no-ops on a second immediate call.
• End-to-end: started the real server, manually placed an orphaned .jsonl file (old mtime, no in-memory record -- simulating exactly the reported scenario), hit GET /execute, confirmed the file was deleted.

Happy to add a tests/ directory with these as real pytest cases if you'd like that as part of this PR rather than a separate contribution.