Frontend upload: validate file size client-side before upload starts

> *This was generated by AI during triage.*

Split out from #1666 (the `accept`-attribute file-picker filter remains there). This issue covers the **client-side file-size pre-check** for AJAX uploads.

## Agent Brief

**Category:** enhancement
**Summary:** On the AJAX file-upload path, reject oversized files client-side *before* the upload starts, instead of uploading the whole file and failing server-side.

**Current behavior:**
On the frontend job-submission form's file field (AJAX upload path), the maximum upload size is shown only as descriptive text ("Maximum file size: …"). There is no client-side size check, so selecting an oversized file uploads the *entire* file before the server rejects it (the original reporter waited 5–10 minutes on a 100 MB file only to then see a size error).

The AJAX upload script validates file **type** and **file-count** in the upload field's `add` handler, but on a validation failure it still calls the upload's `submit()` — so today's client-side validation records an error message without actually preventing the upload. The maximum upload size is not currently exposed to the script.

**Desired behavior:**
- Expose the server's maximum upload size (`wp_max_upload_size()`) to the AJAX upload script — e.g. as a data attribute on the file input and/or a localized script value.
- In the upload field's `add` handler, before the upload begins, compare the selected file's `size` (File API) against that maximum. If it exceeds the limit, surface a clear size error and **abort** — do not start the upload.
- Fix the existing flow so that **any** validation failure (size, type, or count) prevents the upload from being submitted, rather than recording an error and submitting anyway. The size check is just one more reason to block.
- Server-side size enforcement remains the source of truth; the client-side check is a UX shortcut only, not a security boundary.

**Key interfaces:**
- The AJAX file-upload script's per-file `add` handler that currently builds an `uploadErrors` list and then calls the upload's `submit()`. It must not submit when `uploadErrors` is non-empty, and it must add a size check.
- The `file` form-field template that renders `` and already emits allowed-type data — add the max-upload-size value here (or via the script's localization data).
- A user-facing, translatable error message for the oversized-file case (mirror the existing invalid-type / over-limit message handling).

**Acceptance criteria:**
- [ ] Selecting a file larger than the server max on the AJAX path shows a size error immediately and does **not** upload the file.
- [ ] Selecting a file within the limit uploads as before.
- [ ] A type or file-count validation failure now also prevents the upload (no `submit()` on error).
- [ ] The max upload size used client-side equals `wp_max_upload_size()`.
- [ ] The oversized-file error message is translatable.

**Out of scope:**
- The `accept`-attribute file-picker filter (tracked in #1666).
- The non-AJAX/standard upload path (no JS hook there; server-side validation already covers it).
- Changing the server-side max upload size or its enforcement.

Start with the AJAX file-upload script's per-file add handler and the file form-field template that renders the file input. Trace how wp_max_upload_size() and existing type/count errors reach the frontend, then verify that invalid files do not submit, valid files still upload, and the size message is translatable.

Written by the indexing model from the issue text.