Closes: oapi-codegen#155

The reflect.Slice case handled the base64 `format: byte` path and then
fell through, with a comment claiming it landed in the default error
case. It did not: the next case is the integer one, so a non-byte slice
destination reached v.OverflowInt on a slice reflect.Value and panicked.
Only sources that parse as an integer got that far — ParseInt failed
first for anything else, masking the bug behind a plausible-looking
error.

This was reachable from generated server code. A nullable slice query
parameter using the default form/explode serialization binds through the
primitive path, and the nullable wrapper then binds the raw value into a
fresh slice, so `?p=123` panicked while `?p=abc` returned a binding
error.

Replace the fallthrough with the explicit unhandled-type error, which
restores the pre-v1.2.0 behavior (the fallthrough came in with 224825a,
first released in v1.2.0) and makes the comment true. A []byte
destination without Format "byte" took the same panicking path and now
reports the same error; that path never bound successfully, so nothing
could have depended on it.

Regression tests pin both the numeric and non-numeric sources against
[]string, []int and []byte, plus the nullable.Nullable[[]string]
exploded-query route through both BindQueryParameter and
BindRawQueryParameter.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>