The pod env builder filters out any value equal to 0:

    if _val not in (None, "", 0, 0.0):
        env[_var] = str(_val)

and in Python `False == 0`. A boolean sent through that loop can only
ever be switched on: `ocr.early_loop_abort: false` was silently
discarded and the pod ran with the feature enabled.

That is the worst shape a configuration bug can have -- the setting is
in the config, the operator believes it applied, and the behaviour is
the opposite of what it says. It is also how this was found: the early
loop abort could not be A/B tested at all, because there was no way to
send a pod "off".

There was already a boolean loop beside it, writing "1"/"0" explicitly
for `surya_repair_accents` and `surya_token_trace`. The new flag simply
was not added to it. It is now, along with the three thresholds -- which
ARE ints and belong in the int loop, since 0 there properly means "use
the default".

The int filter is deliberately unchanged: for an int, 0 means "use the
engine's own default", and forwarding it would override that default
with a meaningless zero.

7 tests, including a guard that no boolean declared on OcrConfig is sent
through the int loop, so the next one cannot repeat this.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM