fix(config): fall back to defaults on malformed numeric config values

[joaovictor91123]

What changed

recall.load_config()'s max_chars and capture.load_config()'s
min_observations/dedup_window_seconds now go through a new shared
coerce_numeric() helper in config_coerce.py instead of bare
int()/float() calls. compile.py's local _coerce() — which already
implemented this exact fail-soft pattern for its own numeric fields — is
removed in favor of the shared helper.

Why

Both load_config() functions promise "fall back to defaults" on
malformed config, and their boolean enabled field already honors that
via coerce_bool, but their numeric fields didn't: a config typo like
max_chars: "12,000" raised ValueError straight out of load_config.
recall.load_config backs the SessionStart hook with no exception
handling around the call, so one bad numeric value crashed recall-digest
injection on every new session; capture.load_config backs session-split
capture and codex rollout ingestion the same way.

Confirmed with a repro: recall.load_config(store) on a KB with
max_chars: "12,000" raises ValueError: invalid literal for int() with base 10: '12,000' instead of falling back to DEFAULT_MAX_CHARS.

Fixes #685

What might break

Nothing for users with an existing .vouch/ directory — no on-disk
shape, kb.* method, or object model change. Behaviorally: a malformed
numeric config value now degrades to the default instead of raising —
strictly the documented, intended contract. A valid numeric value parses
identically to before.

VEP

Not applicable — no object model, kb.* method, on-disk layout, bundle
format, or audit-log shape change. A config-parsing robustness fix, plus
consolidating a helper that already existed in one module into the
shared one two other modules already use for the boolean case.

Prior art

This exact defect and fix were previously submitted as #488
(fix(config): fall back to defaults on malformed numeric config values, CodeRabbit-reviewed with no substantive objections) but closed
unmerged on 2026-07-29 purely for going stale against test
(src/vouch/capture.py and src/vouch/recall.py conflicts) — the
maintainer's closing comment explicitly said this wasn't a judgment on
the change. Re-verified independently against current test HEAD: only
the boolean coercion was separately fixed since; the numeric gap is
still live. This PR reintroduces the fix, freshly rebased, structured as
a shared coerce_numeric() (matching the existing coerce_bool()
pattern) rather than three separate local copies.

Tests

• Local make check-equivalent: ruff clean (src + tests); mypy
  clean on all four changed source files; 83 tests across
  tests/test_recall.py, tests/test_capture.py, and the relevant
  tests/test_compile.py case pass — two pre-existing, unrelated
  failures in test_compile.py (test_jsonl_kb_compile_files_ proposals, test_two_phase_compile_drafts_planned_pages) are a
  Windows-only stub-LLM python3 invocation issue, confirmed
  identical via git stash comparison against unmodified test
  HEAD; CI runs on Linux
• New / changed behaviour has a test —
  test_load_config_malformed_max_chars_falls_back (recall),
  test_load_config_malformed_numeric_falls_back (capture);
  compile.py's existing test_load_config_bad_values_fall_back_to_defaults
  continues to pass unchanged against the now-shared helper
• CHANGELOG.md updated under ## [Unreleased]

[plind-junior]

the consolidation is the right shape: compile._coerce already was coerce_numeric under another name, and moving it next to coerce_bool in config_coerce.py means the next module that reads a numeric config key finds the fail-soft version first instead of reaching for bare int(). deleting the local copy rather than leaving both is what makes it a consolidation.

the recall.load_config case is the one that justifies the change on its own — it backs the SessionStart hook with no exception handling around the call, so a single typo'd max_chars took recall-digest injection down on every new session, silently, for a value that has a perfectly good default sitting right there.

two things worth a look, neither blocking:

coerce_numeric(value, default, int) will happily accept a bool, since int(True) is 1 — so min_observations: yes in yaml parses to True and lands as 1 rather than falling back to the default. it is a strict improvement over raising, but it is also the one malformed shape that still passes through silently instead of degrading to the documented default. an isinstance(value, bool) guard before the cast would close it, if you think that is worth the line.

and int(12.9) truncating to 12 is the same story — arguably fine, but it means min_observations: 2.9 is honoured as 2 rather than treated as malformed. worth a sentence in the helper's docstring saying which of these are deliberate, since "fall back to defaults on malformed values" currently reads as stricter than the implementation is.

the prior-art note on #488 is useful context and matches what i see — the boolean half landed separately since, the numeric gap did not.