gcvctor: doc clarifications for known traps (BytesValue vs BytesFromSlice, ArrayValue spread, StringBasedValueFromCode scope)

[apstndb]

Problem

gcvctor doc clarifications for known traps (all documentation-only):

• BytesValue(nil) vs BytesFromSlice(nil). The former returns non-null empty BYTES (base64 ""), the latter typed NULL — an easy trap when refactoring between them; only nullable_input.go hints at the distinction. Add a one-line cross-reference on BytesValue (and vice versa).
• ArrayValue(vs...) with an empty slice silently yields ARRAY<INT64>. The zero-argument default is documented, but at a spread call site an empty slice of STRINGs materializes an INT64-typed empty array — a silent type bug. Steer the doc examples toward ArrayValueOf / EmptyArrayOf for slice-spread call sites.
• StringBasedValueFromCode accepts ARRAY/STRUCT codes, producing a malformed simple Type (no array_element_type / struct_type); the doc only warns about NUMERIC normalization. Add "simple scalar codes only; ARRAY/STRUCT shapes require typector".
• NullOf(nil) family normalizes to TYPE_CODE_UNSPECIFIED rather than erroring — deliberate and documented, but add a note that Spanner will reject the sentinel, so a nil-Type bug surfaces at the server, not at construction.

From the usability review accompanying the full-codebase review (#200-#214).

[apstndb]

Proposed addition to this doc-clarification batch, from building spanenc on gcvctor:

• Non-finite FLOAT64/FLOAT32 wire forms: response-side vs client-send asymmetry. Float64Value/Float32Value encode NaN/±Inf as the string wire forms ("NaN", "Infinity", "-Infinity") — this matches what Spanner returns, but the official client's encodeValue sends a raw protobuf NumberValue for all floats (both are accepted by Spanner, and the client decodes both). The current doc comment says "matching Spanner's encoding", which reads as if the client sends strings too. A one-line clarification would preempt confusion for anyone comparing gcvctor output against client-built params byte-for-byte; spanenc documents this as a deliberate divergence on its side (package doc).

[apstndb]

Priority raised (spanenc downstream). Non-finite FLOAT wire-form clarification will land via update to open PR #230.