Replace unmaintained github.com/tmthrgd/go-hex with stdlib encoding/hex

`github.com/tmthrgd/go-hex` has been unmaintained for ~7 years (last commit 2019). We'd love to use `bun` but our SBOM/supply-chain scanning flags it as an abandoned dependency. Since bun uses only two API-compatible functions from it afaik, I'd like to propose to replace it with the standard go library `encoding/hex`. ### Where it's used (quick search in the repo) The dependency is imported in `internal/hex.go` - aliased as `fasthex`, using: - `fasthex.EncodedLen(...)` - `fasthex.Encode(...)` Every other `hex` reference in the codebase (again quick search in the repo) already uses stdlib `encoding/hex`. It's listed as a direct dependency in the root `go.mod` and as `// indirect` across the dialect/example modules. ### Why we'd want to replace it - It's currently unmaintained: if a defect/vulnerability were found, there's no upstream to patch it. (There are no known CVEs today — currently this is _only_ a maintenance/supply-chain concern) - A dependency could be droppen: rather than swapping one third-party lib for another - `encoding/hex` is maintained by the Go team and patched through normal Go releases. - AFAIK it would be API- and behavior-compatible: `EncodedLen` and `Encode` have identical signatures and semantics, so the SQL output should be unchanged. ### The only tradeoff I can see `go-hex` provides SIMD-accelerated encoding, so stdlib `encoding/hex` may be slower when serializing large `[]byte`/`bytea` blobs. I guess for most workloads this is is probably negligible, but maybe someone can include a benchmark on a representative blob size if maintainers want to quantify it before deciding. Happy to open a PR if this direction is acceptable.