[AsParameters]: reject unparseable values in collection query parameters (GH-3398)

[jeremydmiller]

Closes #3398. For 6.18.0. Reported by @outofrange-consulting — thank you. (Supersedes #3402, which was accidentally cut on top of another branch; identical commit, rebased onto main.)

The bug

An unparseable value in a collection query parameter silently bound null instead of returning 400:

• ?colours=Purple (invalid enum) → 200 OK, Colours == null
• ?colours=Red&colours=Purple → 200 OK, Colours == null — the valid Red is dropped too
• Same for int[] / Guid[] / long[].

null is indistinguishable from "parameter omitted", so on a filter endpoint this silently drops the predicate and returns an unfiltered 200. FluentValidation cannot compensate: it sees null, so RuleForEach has nothing to iterate. A silently wrong answer is the worst failure mode available here.

Root cause

Two codegen frames handle collection binding and neither knew about the #3372 strict flag:

• CodeGen/ParsedArrayQueryStringValue.cs (T[])
• CodeGen/QueryStringHandling.cs → ParsedCollectionQueryStringValue (List<T> / IList<T> / IReadOnlyList<T> / IEnumerable<T>)

Both emit foreach + if (TryParse(...)) list.Add(...) with no else, so a bad element is simply dropped. The array frame then does if (list.Any()) prop = list.ToArray(); — so an all-bad collection leaves the property null, and a mixed one silently binds a partial filter.

The fix — completes #3372

#3372 fixed the scalar case (shipped 6.17.1/6.17.2). Both collection frames now take the same rejectUnparseableValue flag, wired from WolverineHttpOptions.RejectUnparseableQueryValues through HttpChain.TryFindOrCreateQuerystringValue, and emit a shared StrictQueryBinding.WriteRejectionBlock that calls the existing HttpHandler.WriteQueryValueParsingProblem.

Semantics mirror the scalar case exactly:

• present-but-unparseable → 400 ProblemDetails naming the parameter
• omitted entirely → keeps its initializer, in both modes
• flag off → today's lenient behavior, byte-for-byte. The default is unchanged (it flips to strict in Wolverine 7.0).

All-or-nothing, deliberately

One bad element rejects the whole collection. Binding [Red] from ?colours=Red&colours=Purple would still be exactly the silently-wrong-answer this issue is about — the caller asked to filter on two values and would get results filtered on one, with a 200 and no signal. Minimal APIs likewise fail the request rather than hand back a partial collection. Rationale is in the docs too, not just here.

Verification

• Red first: precisely the 6 new strict-mode tests failed (Failed: 6, Passed: 17) while the lenient/omitted/valid tests already passed — confirming the change is confined to the flag and cannot alter default behavior.
• Green: strict_query_string_binding 23/23.
• Full Wolverine.Http.Tests 844 passed, 0 failed (net9.0).
• Full wolverine.slnx Release build: 0 warnings, 0 errors.
• Docs: as-parameters.md gains a Collections subsection (behavior matrix + rationale); querystring.md and the RejectUnparseableQueryValues XML doc note collection coverage.

🤖 Generated with Claude Code