fix(handler): preserve request order for repeated query-string params

[zmstone]

Root cause

minirest_handler:parse_qs/1 folds over cowboy_req:parse_qs/1 (which yields pairs in request order) with lists:foldl while prepending each repeated value, so multi-value query parameters reached handlers in reverse request order: /qs_params?array=foo&array=bar arrived as [<<"bar">>, <<"foo">>].

Fix

Fold with lists:foldr instead. The last occurrence is seen first (stored as the scalar), and each earlier occurrence prepends in front of it, yielding request order. Single-occurrence params are unchanged (still a bare scalar, not a list); valueless flags (?foo → true) are unchanged as well.

Behavior change

This is an observable ordering change for any consumer of multi-value query params: they now arrive in request order instead of reversed. The reversed order was an undocumented fold accident, and no known consumer relies on it. Known consumers want request order — emqx/emqx#18267 promises "results in query-parameter order" for GET /clients?clientid=a&clientid=b, and the order-sensitive tests in emqx/emqx#18268 tripped over the reversal. The existing t_qs_params test asserted the reversed order; it is flipped and strengthened to three occurrences.

Follow-ups (not in this PR)

• Tag the next minirest release and bump the pin in emqx.git (currently 1.4.12).