fix(apiform): preserve float32 precision in comma arrays

[sylvesterkaczmarek]

Summary

Keep multipart comma-array float32 serialization consistent with the existing scalar float32 path.

Fixes #77.

Problem

internal/apiform already formats scalar float32 values with 32-bit precision, but FormatComma arrays combine float32 and float64 behind a 64-bit formatting call.

That means the same source value can be represented differently depending only on whether it appears by itself or inside a comma-delimited form field.

For example, current main serializes:

float32(0.1)

as:

0.1

but:

[]float32{0.1, 1.5}

with FormatComma as:

0.10000000149011612,1.5

Root cause

The primitive form path correctly distinguishes widths:

case reflect.Float32:
    strconv.FormatFloat(val.Float(), 'f', -1, 32)
case reflect.Float64:
    strconv.FormatFloat(val.Float(), 'f', -1, 64)

The comma-array path instead uses one branch for both kinds and always passes bitSize=64. Reflection returns floating-point values as float64, so the 64-bit formatting request preserves digits introduced by widening the original float32.

Fix

Split the comma-array branch by source kind:

• reflect.Float32 -> FormatFloat(..., 32)
• reflect.Float64 -> FormatFloat(..., 64)

No multipart boundaries, field names, array-format selection, integer formatting, boolean formatting, or float64 output changes.

Regression coverage

The existing table-driven form encoder test now includes:

• a scalar float32(0.1) control showing the existing expected representation;
• a FormatComma []float32{0.1, 1.5} regression requiring 0.1,1.5.

The comma-array case fails on current upstream main, while the scalar control demonstrates the consistency requirement directly.

Validation

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

Production diff: 3 additions and 1 deletion in internal/apiform/encoder.go, plus focused table-driven coverage in internal/apiform/form_test.go.

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

Risk

Low. Only the textual formatting of float32 values inside FormatComma arrays changes, and it becomes identical to the width-aware behavior already used for scalar float32 fields. float64 and all non-floating form values are unchanged.