fix(apiquery): reject non-string map keys

[sylvesterkaczmarek]

Summary

Fail clearly when URL-query encoding receives a map whose keys are not strings, instead of serializing reflection placeholder text into parameter names.

Fixes #87.

Problem

internal/apiquery.encodeMap currently assumes every map key is a string and calls:

subkey := iter.Key().String()

without checking the key kind.

For a non-string reflect.Value, String() is not a conversion of the underlying key. It returns reflection's diagnostic representation. A value such as:

map[int]string{1: "one"}

can therefore proceed into request encoding with a malformed implementation-specific query key instead of failing at the serialization boundary.

Root cause

The map encoder relies on a string-key invariant that it never validates.

The sibling multipart/form encoder already rejects non-string map keys explicitly, so the two request encoders currently disagree on the same unsupported input shape.

Fix

Inspect each map key before using it:

mapKey := iter.Key()
if mapKey.Kind() != reflect.String {
    return nil, fmt.Errorf("apiquery: cannot encode a map with a non-string key")
}

String-key behavior and nested query formatting remain unchanged.

Regression coverage

Added focused tests proving:

• map[int]string{1: "one"} returns a clear error and no query values;
• an ordinary map[string]string continues to encode normally.

The invalid-map case exercises the public Marshal path rather than calling the internal encoder directly.

Validation

The branch is based directly on upstream main at d082a010f7c6cacf407d8a1581446a7857f9f1bb and is not behind it.

Production diff: 5 additions and 1 deletion in internal/apiquery/encoder.go, plus one focused regression file.

Full repository validation is left to the repository's GitHub Actions checks.

Risk

Low. The only newly rejected inputs are map shapes that cannot preserve their key semantics in URL query parameter names. Existing string-key maps, arrays, primitives, and nesting formats are unchanged.