fix(entrypoint): INPUT_MAX_RETRIES=0 + 5h timeout per attempt = unbounded total runtime

gh issue create --title "fix(entrypoint): INPUT_MAX_RETRIES=0 + 5h timeout per attempt = unbounded total runtime" --label "bug,audit,priority:high" --body "## Finding

When INPUT_MAX_RETRIES=0 (retry forever), each attempt can run for up to the timeout (default 5h, configurable). Without an upper bound on the total number of retries, the action can run until the GitHub Actions job timeout (6h). On a self-hosted runner with no job timeout, the action runs indefinitely and exhausts the runner.

INPUT_MAX_RETRIES=0 means 'retry forever' (per the action.yml description). It should also cap the total wall-clock time, not just the per-attempt time.

## Affected code

- entrypoint.sh — retry loop around run_lftp_once

## Reproduction

1. Set INPUT_MAX_RETRIES=0 (or omit it; default may be 0).
2. Point the action at a server that always times out.
3. Observe the action retries for the full job timeout.

## Suggested fix

Either:
- Cap total retries with a separate INPUT_MAX_TOTAL_TIME / INPUT_MAX_TOTAL_ATTEMPTS input.
- Or, when INPUT_MAX_RETRIES=0, compute a sensible default (e.g. min(20, job_timeout / per-attempt-timeout)).
- Or, document that INPUT_MAX_RETRIES=0 means 'retry until job timeout' and require the caller to set an explicit job-level timeout.

## Source

F2 audit 2026-09-03 (entrypoint.sh audit). Reporter: subagent-pekodbj7.

## Related

- Part of EPIC #[epic-number]
- Closes: #NONE (no existing issue)
- Related: #49 (max_retries=0 should mean 'retry forever') — already closed; this is the residual"

Start with the retry loop around run_lftp_once in entrypoint.sh and read the INPUT_MAX_RETRIES description in action.yml; review the relationship to closed issue #49. Decide which total-runtime behavior is intended, then verify that INPUT_MAX_RETRIES=0 cannot run beyond the documented bound and that the chosen configuration or documentation is consistent.

Written by the indexing model from the issue text.