harden: malformed-input hardening, non-panicking encoders, unit coverage

[MattJackson]

Robustness hardening and broad unit-test coverage across the codec/token layer.

• Bounds/robustness hardening across codec and token decoders against malformed server input.
• Non-panicking var-len encoders; DONE-status leniency.
• AAD-token redaction/zeroize; numeric rescale to column scale instead of panicking.
• Broad in-crate unit-test coverage across decoders, time, tokens, config.

Squashed into a single commit (all the submitter's own work — no external authorship to preserve here).

Supersedes: none.

Sequential series — merge after #432–#435. Based on main; diff reduces to its own delta as the earlier PRs land.
Reviewer note: rebase-merge or merge-commit, not squash (keeps the series consistent).

[victorchutw]

Thanks for lifting the scale < 38 assertion in Numeric::new_with_scale — DECIMAL(38,38) is a valid SQL Server type, and the released 0.12.3 panics on it (assertion failed: scale < 38, src/tds/numeric.rs:35).

One half of the invariant is still missing on this branch: Numeric::precision() counts a phantom integral digit when the integral part is zero (1 + scale), so a fraction-only scale-38 value is described as numeric(39,38), which SQL Server rejects as a type. Reproduction on this PR's head (394574729ea48776a127b280eab623ac718779d4):

let n = Numeric::new_with_scale(-1, 38);
assert_eq!(n.precision(), 39); // passes today; the only valid answer is 38

precision() feeds ColumnData::type_name() (the numeric(p,s) in the RPC parameter declaration) and the NUMERICNTYPE TYPE_INFO header written when no destination type info is available, so SELECT @P1 with such a value declares @P1 numeric(39,38), above SQL Server's maximum precision of 38, even with the assertion lifted. The precision_with_zero_int_part test in this PR pins the 1 + scale behaviour, so this is a request to change it rather than a regression report.

The complete invariant, as far as I can tell: with no integral digits, precision = max(scale, 1) — 0.05 is numeric(2,2), zero at scale 0 stays numeric(1,0), and a scale-38 fraction is numeric(38,38); with integral digits, keep integral_digits + scale. The rust_decimal and bigdecimal conversions route through the same constructor and precision(), so they inherit the fix. A side effect worth knowing: fraction-only values at scales 9, 19, and 28 move down one wire-length bucket (5/9/13 bytes instead of 9/13/17), which SQL Server 2022 accepts on both the RPC and bulk paths.

I am carrying exactly that change as a focused patch on top of the 0.12.3 sources: victorchutw@65c1a32 — the constructor bound, the precision correction, unit tests (construction, precision, length buckets, encode/decode round trips, TYPE_INFO bytes, scale-39 rejection), and live SELECT @P1 plus bulk-insert round trips of DECIMAL(38,38) boundary values and the bucket-edge fractions, all green against SQL Server 2022. Happy to open it as its own issue and PR against main if you would rather keep this series as is.

[MattJackson]

Superseded by #443. Re-opened as a native GitHub stacked PR (stack #445) per @aqrln's request in #440 — the fork origin of these PRs made a native stack impossible (GitHub can't add fork-head PRs to a stack), so the branches now live in tiberius-rs/tiberius directly. Same commits, same authorship. Please review #443 instead.