feat(assert): add numeric range assertions

[w3lld1]

Background

Related #1026

Numeric assertions covered open-ended comparisons but not a single inclusive range check. I added bounded assertions so one logical range check reports one result and one failure message.

Changes

• I added assert_between <min> <max> <actual> with inclusive bounds and assert_not_between as its exact negation.
• I reused the fork-free fixed-point comparison path for common integers and decimals, with the existing bc/awk fallback for unsupported precision.
• I return usage errors for missing arguments, non-numeric values, and reversed bounds.
• I added coverage for boundaries, decimals, negative values, failure details, assertion counts, arity, and invalid input.
• I updated the assertion docs, generated CLI snapshot, completions, catalogue counts, and changelog.

Verification

• make test — 1,789 passed; 32 skipped; 4 incomplete; 2 snapshots; no failures
• ./bashunit --parallel tests/ — 1,751 passed; 35 skipped; 4 incomplete; 2 snapshots; no failures
• focused assertion, arity, completion, and fork-budget suites — 85 passed; 1 skipped; no failures
• make sa
• make lint
• git diff --check

Checklist

• I updated the CHANGELOG.md to reflect the new feature or fix
• I updated the documentation to reflect the changes

Fixes #1026

[Chemaclass]

Approved.

Solid feature. Inclusive bounds, an exact negation, usage errors for reversed and non-numeric input, and a failure message that names which bound broke. Docs, both completion files, the doc snapshot, the arity provider and the CHANGELOG are all updated.

Verified locally: full suite, --parallel, make sa, make lint, and no new shfmt drift against main.

I pushed one fix on top (fb697ec).

assert_between "+1" "+9999999999999999999999" "+5" leaked a raw bc parse error and then reported a bogus expects min <= max usage error. Operands wider than the fork-free fixed-point path fall through to bc, and bc cannot parse a leading +: it returns an empty result, which is_le reads as "greater than". assert_within_delta already strips the sign for exactly this reason, so bashunit::math::is_le now does it for every caller. Regression tests in math_test.sh and numeric_test.sh.

I also pinned the _is_numeric hardening this branch introduces. That is a user-visible fix on its own and it was not recorded: on main, assert_within_delta "1.2.3" "1" "0.5" leaks Parse error: bad expression into the report, and 5-3 is silently evaluated as 2. Two regression tests plus a Fixed entry in the CHANGELOG.