fix: validate numeric defcustoms at customize-time

Six numeric settings are declared as integers but were read straight into
arithmetic and timer math.  A bad value (string, negative number, nil where
nil isn't supported) used to slip past the defcustom and surface as a
timer error or `arith-error' deep in a callback, instead of as a
configuration problem at the moment the user set it.

I added `chime--validate-integer-setting' as a small shared helper and
wired a `:set' on each of the affected defcustoms:

- `chime-modeline-lookahead-minutes' — integer >= 0 (0 disables)
- `chime-tooltip-lookahead-hours'    — integer >= 1
- `chime-modeline-tooltip-max-events' — integer >= 1 or nil (show all)
- `chime-day-wide-advance-notice'    — integer >= 0 or nil (same-day only)
- `chime-max-consecutive-failures'   — integer >= 0 (0 disables warnings)
- `chime-validation-max-retries'     — integer >= 0 (0 = fail immediately)

The constraints follow each docstring's stated intent.  The helper signals
`user-error', so `customize-set-variable' surfaces it as a config problem
rather than a generic error trace.

Tests: 22 cases in `tests/test-chime-numeric-defcustom-setters.el' —
five direct on the helper plus each defcustom's accept/reject paths
through `customize-set-variable'.

0 files changed, 0 insertions, 0 deletions