A malformed CBM_* environment value silently picks a wrong setting at three sites

[CaptainMittens]

Version

Built from source at ae5de7fe (main), release line v0.10.8

Platform

macOS (Apple Silicon)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

atoi and atol answer 0 for text they cannot read, and 0 is a real setting at three
places in this project. So a typo, a trailing unit such as 30s, or a stray space
silently chooses a value nobody asked for, and nothing on screen says the setting was
dropped.

Site	Setting	What a typo does
src/cli/hook_augment.c	CBM_HOOK_DEADLINE_MS	returns the shortest deadline the setting allows
src/mcp/mcp.c	CBM_INDEX_MAX_RESTARTS	keeps 100, and so does an explicit =0
src/mcp/index_supervisor.c	CBM_INDEX_WORKER_TIMEOUT_S	keeps the 15-minute default

The first is the sharpest. The code reads:

int v = atoi(env);
if (v < HA_DEADLINE_MIN_MS) {
    return HA_DEADLINE_MIN_MS;
}

atoi answers 0, 0 is below HA_DEADLINE_MIN_MS, and the clamp hands back 50 ms
— for a setting whose only purpose is to give the hook more room. The comment directly
above that function records a hunt for hook runs that never finished, 0 of 24 real
sessions, which is the exact symptom a silently-shortened deadline produces.

I expected an unreadable setting to be rejected with a message naming the variable, or at
minimum to fall back to the documented default rather than to the opposite extreme.

Reproduction

1. Set a deliberately malformed value, e.g. export CBM_HOOK_DEADLINE_MS=30s (a plausible
   typo — the variable name ends in _MS, so a unit suffix reads as natural).
2. Run the hook path that consumes it.
3. Result: the deadline becomes 50 ms, the shortest the setting allows, with no message.
   Expected: either an error naming CBM_HOOK_DEADLINE_MS, or the documented default.

The other two sites reproduce the same way with CBM_INDEX_MAX_RESTARTS and
CBM_INDEX_WORKER_TIMEOUT_S. Note that at CBM_INDEX_MAX_RESTARTS an explicit =0 and a
typo are indistinguishable today, so a user cannot switch restarts off.

Logs

No message is emitted for a rejected value — that is the defect.

Diagnostics trajectory (memory / performance / leak issues)

Not applicable — a correctness issue, not memory or performance.

Project scale (if relevant)

Reproduces at any scale.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Thank you for grouping the three environment parsing failures while preserving their different policies. PR #1880 is the focused implementation: one strict reader, with deadline, restart-cap, and worker-timeout behavior still decided at each call site. Leaving this issue open until that PR lands.