docs: recommend f32 scales for asymmetric codes above about 10 bits

[aksheyd]

The README and the asymmetric.quantize docstring offered 2 to 16 bits with any scale type, with no caveat. But f16 and bf16 store each block's zero-point too, and at high bit widths their rounding of it outgrows the codes' own rounding.

Worst error relative to f32 scales, on 65,536 normal weights with blocks of 32:

bits	asymmetric f16	asymmetric bf16	symmetric f16 / bf16
10	1.0×	1.0×	1.0×
11	1.0×	2.3×	1.0×
12	1.0×	4.6×	0.9×
14	2.1×	18×	1.0×
16	6.9×	71×	1.1×

On blocks far from zero, like LayerNorm gains around 1, it starts sooner: bf16 is 3× worse at 8 bits and f16 1.5× at 10.

• the README's paragraph on what scales cost gets one line: above about 10 bits, use f32 scales with asymmetric.quantize
• the asymmetric.quantize docstring says the same, and that blocks far from zero hit it sooner, as the Rust asymmetric docs already say
• the Scale docstring says it too

Symmetric codes are unaffected, so quantize's docstring stays as it is. Adaptive codes stop at 8 bits, and its docstring already covers blocks far from zero.

PyPI keeps each release's README as uploaded, so this is worth having in 0.3.0. Merges cleanly with #101, #103, and #106. just lint, just test, and just python pass.