Harden validation, optimize encoding, and add test coverage

[klaidliadon]

Summary

• Validation hardening: reject zero UUID and non-positive Int64 consistently across MarshalText, Value, and Scan; fix UUID.Scan to handle raw 16-byte []byte from binary SQL drivers (e.g. pgx)
• Encoding optimization: switch to append-style encoding with pre-sized buffers — String/MarshalText down from 2 allocs to 1, ~30% faster
• Test coverage: negative-path tests for Parse/Scan/Marshal, known-vector roundtrip tests, benchmarks
• Cleanup: sentinel errors replace repeated fmt.Errorf, tighten splitTypeid, drop redundant ErrNegativeInt

Breaking changes

• Int64From(0) now returns ErrNonPositiveInt (previously succeeded but produced an unusable ID)
• ErrNegativeInt removed, replaced by ErrNonPositiveInt

Benchmarks

BenchmarkInt64_String         ~19 ns/op    24 B/op    1 allocs/op
BenchmarkInt64_MarshalText    ~18 ns/op    24 B/op    1 allocs/op
BenchmarkInt64_Parse          ~18 ns/op     0 B/op    0 allocs/op
BenchmarkUUID_String          ~24 ns/op    32 B/op    1 allocs/op
BenchmarkUUID_MarshalText     ~23 ns/op    32 B/op    1 allocs/op
BenchmarkUUID_Parse           ~33 ns/op     0 B/op    0 allocs/op

Test plan

• go test ./... passes
• go test -bench=. -benchmem shows 1 alloc on encode, 0 on decode
• Known-vector tests verify encode/decode determinism
• Negative-path tests cover invalid input, wrong types, zero/negative values

[VojtechVitek]

LGTM. Thank you!

[VojtechVitek]

I'm not sure if we want to export this error type / expose it to the pkg API.

Is there a reason why devs would need to know this exact sentinel error?

[VojtechVitek]

agreed