fix(lib): INPUT_MAX_RETRIES=0 (retry-forever) combined with v2.11.9 append-mode log lets the log file grow unbounded

## Finding

The v2.11.9 fix in `lib.sh:1074` switched `>` to `>>` so retries preserve their history. Combined with `INPUT_MAX_RETRIES=0` (the documented retry-forever sentinel) and the 5h hard timeout per attempt, the log file can grow to tens of MB across ~600 retries (30s backoff + ~5s lftp each).

When `INPUT_UPLOAD_LOG_ON_FAILURE=true`, this exceeds GitHub's per-artifact size cap and the artifact upload step itself fails with HTTP 413.

The non-zero retry path is also affected — `INPUT_MAX_RETRIES=10` (the default) plus a server that's permanently unreachable accumulates ~30-50 KB of identical error messages.

## Affected code

- `entrypoint.sh:344-415` (retry loop)
- `lib.sh:1074` (v2.11.9 append change)
- `lib.sh:1569-1665` (`upload_log_artifact`)

## Suggested fix

Either:

(a) Rotate the log on each attempt (rename `run-…log` → `run-…log.1` before each retry, keep the last N attempts).

(b) Cap per-attempt log size with `ulimit -f` or by running lftp under a wrapper that truncates at N MB.

(c) Keep only the last N attempts in the appended log by snapshotting the file size at the start of each retry and `tail -c`-ing the diff.

(d) Switch back to truncate mode (`>`) and write a separate `.history` file with one entry per attempt, for users who want the full history.

## Pending design decision

The right fix depends on what `upload_log_on_failure` is meant to deliver (last attempt only? full history? first failure only?). See related issue on the broken artifact endpoint — the upload may not work regardless.

## Source

F2 audit round (post-v2.11.9 release), 2026-09-06.