fix(proto): encode nil *uint8 as "0" like other numeric pointers

[sueun-dev]

WriteArg encodes a nil pointer to a numeric type as its zero value. Every nil *int, *int8, *int16, *int32, *int64, *uint, *uint16, *uint32, *uint64, *float32, *float64, *bool and *time.Duration encodes as "0". The *uint8 case returned an empty string instead.

It is also inconsistent with the non-nil *uint8 path, which writes the number through w.uint. The table test already asserts uint8(10) and *uint8(10) both encode as "10", so uint8 is treated as a number here, not a byte.

In practice var p *uint8; rdb.Set(ctx, key, p, 0) sent "" while every other nil numeric pointer sent "0".

The empty-string branch came in with the other nil-pointer guards in #3271; it looks like the one case that was missed rather than intended behavior.

Note this is a wire-output change for the nil *uint8 case: it now sends "0" ($1\r\n0\r\n) instead of an empty bulk string ($0\r\n\r\n).

Changed the nil branch to w.uint(0) and updated the (*uint8)(nil) expectation in the writer table test.

Tested:

go test ./internal/proto/

---

Note

Low Risk
Single-branch serialization fix in the proto writer with a narrow wire-output change for nil *uint8 only.

Overview
WriteArg now encodes a nil *uint8 as "0" via w.uint(0), matching every other nil numeric pointer type instead of an empty bulk string.

This is a wire-format change for that case only: Redis commands that pass a nil *uint8 (e.g. Set with a nil pointer value) will send $1\r\n0\r\n instead of $0\r\n\r\n. The writer table test expectation for (*uint8)(nil) was updated accordingly.

^{Reviewed by Cursor Bugbot for commit 081addb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ndyakov]

@sueun-dev this makes sense based on the rest uint handling, but let me verify that there is no case where we would like to keep nil as "" in the request.