feat: support more primitives

[freshtonic]

Summary

• Introduces a top-level ToOrderableBytes trait in packages/orderable-bytes/src/lib.rs that replaces the per-type free to_orderable_bytes functions with a single trait carrying const ENCODED_LEN: usize, type Bytes: AsRef<[u8]>, and fn to_orderable_bytes(&self) -> Self::Bytes. Existing chrono and decimal modules and the in-tree ore-rs consumer are migrated to the trait API.
• Adds a new primitive module (packages/orderable-bytes/src/primitive.rs) with 14 ToOrderableBytes impls covering bool, char, every native unsigned and signed integer (u8–u128, i8–i128), and both IEEE 754 floats (f32, f64).
• Wires every primitive into ore-rs end-to-end: OreEncrypt now has impls for all 14 primitives in packages/ore-rs/src/encrypt.rs, all routing through ToOrderableBytes. The previously-bespoke u32/u64/f64 OreEncrypt impls are migrated to the same path so the file is uniform with chrono.rs / decimal.rs. The legacy ToOrderedInteger / FromOrderedInteger bridge in packages/ore-rs/src/convert.rs becomes dead code and is removed.
• Each primitive impl emits the type's native byte width — no padding. Consumers that need a fixed wider encoding (e.g. an ORE construction with [u8; 8] plaintext blocks) can zero-extend upstream of the encrypter; widening is monotonic on lex order so the encoding's guarantees are preserved.

Encoding strategies

• bool — false → 0x00, true → 0x01 (already in lex order)
• Unsigned integers — native big-endian (already in lex order)
• Signed integers — XOR the sign bit at the native width, then big-endian. Moves negatives below positives and preserves order within each sign class.
• char — big-endian bytes of *self as u32. Rust's Ord for char is by code point and surrogates are not representable, so the native u32 lex order is exactly the order we need.
• f32 / f64 — branchless monotonic mapping: negatives flip every bit, positives flip just the sign bit. -0.0 is canonicalised to +0.0 before encoding so byte equality matches -0.0 == 0.0. NaN handling is unspecified — the trait's order/equality contract only applies to non-NaN inputs.

Compatibility

The new f64 byte encoding is bit-for-bit identical to the legacy ToOrderedInteger::map_to::<u64>().to_be_bytes() output (same sign-bit canonicalisation, same XOR mask, same -0.0 → +0.0 collapse), so existing f64 ciphertexts on disk remain comparable against ciphertexts produced by this branch.

Test plan

• cargo test -p orderable-bytes — 32 unit tests in primitive.rs (known-anchor + ascending-order pairs per type, plus 0.0/-0.0/subnormal coverage for both floats); --all-features brings the total to 54 with chrono and decimal quickcheck/property tests passing under the migrated trait API
• cargo test -p ore-rs --all-features — 53 unit tests + 5 doc-tests pass, including the signed_zeros_compare_equal regression test that pins (-0.0).encrypt(&ore) == 0.0.encrypt(&ore)
• cargo fmt --check --all — clean
• In-tree ore-rs consumers (chrono.rs, decimal.rs, encrypt.rs) all call .to_orderable_bytes() via the trait; no per-type bespoke encoding paths remain (verified: zero to_be_bytes / map_to callers in those files)
• char ordering test spans ASCII, BMP, and supplementary planes (crosses the surrogate gap from U+D7FF to U+E000)
• f32 / f64 subnormal tests confirm strict ordering: 0.0 < f*::from_bits(1) < f*::MIN_POSITIVE

[auxesis]

@freshtonic walked me through this on a call, and it looks good.