fix(validate_int): accepts absurdly large values; add an upper bound

gh issue create --title "fix(validate_int): accepts absurdly large values; add an upper bound" --label "bug,audit,priority:medium" --body "## Finding

validate_int accepts any non-negative integer without an upper bound. A user-supplied value of 2^63 - 1 for INPUT_MAX_RETRIES (or any numeric input) silently propagates and produces a retry loop the action cannot realistically complete. Some numeric inputs have an obvious upper bound (mirror_verbose: 0-3, max_retries: practical 10) and should reject the rest.

## Affected code

- lib.sh — validate_int (function)

## Reproduction

1. Set INPUT_MAX_RETRIES to 999999999999.
2. The action accepts it; the retry loop runs until the GitHub Actions job timeout (or, if input is too large, an integer overflow somewhere downstream).

## Suggested fix

Either add per-input upper bounds at the call site in entrypoint.sh (preferred — keeps validate_int generic), or accept an optional 3rd arg to validate_int that is the upper bound and call sites pass one.

## Source

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

## Related

- Part of EPIC #[epic-number]
- Closes: #NONE (no existing issue)
- Related: LOW-3 (leading zeros)"

Start in lib.sh at validate_int, then inspect its call sites in entrypoint.sh. Reproduce the issue with INPUT_MAX_RETRIES set to 999999999999 and determine the existing validation flow for numeric inputs. Done means absurdly large values are rejected while validate_int remains generic or its optional upper-bound behavior is consistently applied at the call sites.

Written by the indexing model from the issue text.