Array-ify repeated plain keys instead of keeping the last value

[botre]

Summary

• A field name repeated without brackets (a checkbox group, a multi-select, multiple file inputs sharing a name) silently kept only the last value — tag=first&tag=second produced { tag: "second" }.
• This diverges from both of Formspark's own backend parsers for the identical input: qs.parse("tags=a&tags=b") (used for url-encoded submissions) and Hono's parseBody({ all: true }) (used for multipart submissions, monorepo PR #100) both already turn a repeated key into an array. formson was the only one of the three that didn't.
• It's also the library formspark/documentation's Webflow integration guide tells developers to wire up in front of every form submission, since Webflow needs client-side JSON conversion — and native checkbox groups (a completely standard Webflow pattern) are exactly the shape that silently loses data through this path today.
• toJSON now promotes a key to an array on its second plain occurrence ([existing, value]) and pushes on subsequent occurrences, while a plain key still correctly overwrites a nested object built via dot/bracket notation (unchanged "nested then scalar overwrites the object" behavior) — the object-vs-leaf distinction is existing.constructor === Object, so this doesn't touch the bracket-array code path at all.
• items[] (empty brackets) shares the exact same code path as a plain repeated key, so it now also produces an array instead of "last value wins" — arguably the more correct reading of that syntax anyway.

Test plan

• Updated the existing "repeated key" and "empty brackets" tests to expect arrays; added coverage for a repeated key at a nested/dotted path and for repeated File values (mirroring the existing bracket-array File test). 32 tests total, all passing.
• npm run typecheck clean, npm run build (tsup) clean.
• Added a short README section documenting the new behavior next to the existing square-bracket-notation docs.
• Bumped to 0.3.0 (from 0.2.1): this changes the output shape for existing inputs relying on last-value-wins, so treating it as a minor bump rather than a patch protects consumers pinned via ^0.2.x.