batch-runner: `--limit 0` means unlimited, which is the opposite of what a caller passing 0 means

Where: batch/batch-runner.sh, LIMIT=0 default and if (( LIMIT > 0 )) guards (currently around lines 53, 1389, 1461).

What happens: --limit N caps the pass at N offers, except N=0, which is the internal sentinel for "no limit". A wrapper or cron job that computes a limit and arrives at 0 (memory pressure, a dry run, a "scan only" pass) launches an unbounded batch instead of none. In one real case a scheduled run passed 0, queued 62 offers and spent roughly 25 minutes of model time on 8 of them before it was killed.

Why it is worth changing: the flag reads as a count; 0 as "all" is only knowable from the source. Every other place a user meets a count (--parallel, --max-retries) treats 0 literally or rejects it.

Suggested fix (any of):

1. Treat an explicit --limit 0 as "process nothing" and print Limit: 0 (nothing to do); keep the unset default as unlimited.
2. Or reject --limit 0 with a one-line error pointing at "omit the flag for no limit".
3. At minimum, print a loud Limit: none (0 = unlimited) in the banner so a log reader sees what is about to happen.

Happy to send the PR for whichever you prefer; it is a few lines either way. Noting it as an issue first because it changes documented behaviour.