The ULID spec notes that IDs within the same millisecond dont need to be
ordered: https://github.com/ulid/spec?tab=readme-ov-file#sorting

Overflow should happen relative to the 80-bit random generated at the
timestamp rather than relative to a separate counter at the timestamp
which is applied to the random.

This provides sort order guarantee using the recommended approach from
the spec: https://github.com/ulid/spec?tab=readme-ov-file#monotonicity

For setups which download both `zig/zig` and `zig/zig.exe` for convenience
(i.e. windows WSL), this ensures the Java CI uses the correct one instead of
relying on shell to append `.exe` (which doesn't happen since non `.exe`
version exists).

ULID spec requires storing the values as big endian which means, when interpreted
by a replica on the Zig side, the `u128` ID is no longer monotonically incrementing.
This resorts in unique but effectively randomly-ordered IDs which doesn't take
advantage of data/lookup optimizations in the storage engine.

Instead, the Java client now exposes a generic `ID()` helper (instead of specifically `ULID`)
which allows us to return u128 bytes in little-endian format while still using the core
ideas around uniqueness & monotonicity from ULID underneath.

Switches to using the 48 LSB of timestamp instead of 16 LSB and 32 MSB. Also updates the data-modeling
documentation to give note about storing ULID fields in little endian.

Standardize upper-case hex literals and refer to ULID spec as `ID()`'s inspiration.