Add file serialization support to the `form` component / `use_form_data` hook

Start with the form component and use_form_data hook, using PR #58 and the original feature in #7 for context. Resolve whether file fields use metadata, multipart upload, or both before implementing. Done means mixed file and regular fields serialize without a reload, the behavior is tested, and documentation is updated.

Description

Follow-up to #58 (the form component and use_form_data hook, which closed #7).

The form component's client-side interception currently serializes non-file fields only. File inputs (<input type="file">) are silently excluded because the submission handler iterates FormData entries and calls .toString() on each value, which for File objects yields [object File] and loses the file content.

The PR description for #58 explicitly deferred this:

Non-file fields only; file serialization is deferred.

Proposed scope

Support forms that contain file inputs, matching how the current behavior treats other input types. Possible options to evaluate:

• Include file metadata (name, size, type, lastModified) in the serialized form data, without uploading file content — useful for validation/UI feedback on the server.
• Defer file content upload to a separate multipart POST when the form is submitted, integrating with the router's navigation model.
• Combination: send metadata for a GET-style/pushState navigation while supporting an optional file payload.

Acceptance criteria

• Defining a form with one or more <input type="file"> fields does not break serialization of the other fields.
• File fields are represented in the use_form_data() output in a well-defined way (currently undocumented behavior).
• No full page reload occurs on submit of a form with file inputs (consistent with #58).
• A test covers a form that mixes file inputs with regular fields.
• Documentation updated for file-field behaviour.

Related

• PR: #58
• Original feature: #7