Optimize ASCII nvarchar encoding in the direct writer

[mag1cfrog]

Summary

• use byte length directly when measuring ASCII values for nvarchar
• widen ASCII bytes directly to UTF-16LE in the direct raw writer
• preserve the existing encode_utf16 fallback for non-ASCII values

Why

The direct raw writer previously used the general UTF-8-to-UTF-16 iterator for every string during both measurement and encoding. ASCII values have a one-byte to one-code-unit mapping, so they can use a simpler byte path without changing the emitted TDS payload.

Performance

Three wide_sparse runs with 1,000,000 rows, 16,384-row batches, and the direct-raw backend:

Metric	Before median	After median	Change
Write	12.684 s	11.217 s	-11.6%
Measure batch	3.212 s	2.294 s	-28.6%
Append/encode	8.708 s	8.128 s	-6.7%

A three-run string_heavy_unicode guard showed measurement and append/encode medians within 0.3% of the prior path, and Unicode sentinel validation passed.

Validation

• cargo fmt --check
• cargo test --all-features
• cargo clippy --all-targets --all-features -- -D warnings