BusinessMath 2.11.1 — A day count that depended on the machine, and a wrong factorial

v2.11.1 — a day count that depended on the machine, and a wrong factorial

Two defects in shipped code. Neither was found by a test this package had; both were
found by comparing against an independent implementation.

actual365, actual360 and both actual/actual conventions depended on the local time
zone. Two instants exactly 181 x 86,400 seconds apart — both UTC midnight — counted
181 days on a machine set to UTC and 181.0417 on one set to New York, because the
span crosses a spring-forward and the local wall clocks then sit an hour apart. Two
parts in ten thousand on every accrual, in the direction of the offset, and invisible
on any UTC runner. thirty360 never had it, because it reads calendar components
rather than an elapsed interval — which is why the suite stayed green.

These conventions now count whole civil days, midnight to midnight, which is also
Excel's model: a date there is a serial number whose whole part is the day. Verified
across fixed offsets, no-DST zones, half-hour offsets, quarter-hour offsets, a
half-hour DST shift and a quarter-hour zone that also observes DST.

logFactorial used the leading terms of Stirling's approximation above n = 20 and
dropped the 1/(12n) correction, making n! 0.4% wrong at n = 21 and discontinuous at
the threshold. It propagated into combination, permutation and hypergeometric. Now
logGamma.

Also adds the parity suite that found the second one: 127 reference cases across 34
Excel functions the coverage matrix marks bindable — computed here, reachable from no
formula, and so never compared to anything but their own definitions.

No API change. 6,881 tests. quality-gate --check all: 45 of 45, 0 errors, 0 warnings.