[Eval] Support uploading multiple suite files in a single endpoint call

### Name and Version

0.1.0

### What is the problem this feature will solve?

The current suite file upload endpoint accepts only **one file per HTTP request**. When a user prepares a test suite that references many attachments (multi-modal test cases, document corpora, image sets, etc.), they must issue one upload request per file. This causes several pain points:

1. **Poor UX** — uploading dozens or hundreds of files from the UI or a script requires many sequential or hand-parallelized calls, with the client responsible for tracking progress, retries, and partial failures.

### What is the feature you are proposing to solve the problem?

Extend the suite file upload capability so that **multiple files can be uploaded in a single endpoint call**, while keeping the existing single-file endpoint working unchanged for backward compatibility.

High-level behavior:

- A single request accepts **N files** belonging to the same suite (e.g. via a `multipart/form-data` payload with repeated file parts).
- Existing per-file rules are applied to every file in the batch: filename validation, max file size, allowed-character set, and the suite-level caps (max files per suite, max total size).
- **Pre-flight validation** — before any file is written to the DIAL bucket, the whole batch is validated against suite-level limits, so the client learns up-front if the batch as a whole would exceed the cap, instead of after some files have already been stored.
- **Partial-success response (default)** — the response returns a per-file result list: each entry indicates the original filename, the resolved DIAL reference (on success), or a structured error code and message (on failure). HTTP status reflects the overall outcome (e.g. all-success, mixed, all-failed).
- **Atomic mode (optional, nice-to-have)** — a request flag that, when set, makes the batch all-or-nothing: if any file fails validation or upload, all already-uploaded files in the same batch are rolled back from the bucket so the suite state matches what the client sees in the response. Whether this is implemented in v1 depends on implementation cost; if costly, it can be deferred to a follow-up while the partial-success mode ships first.
- **Limits and quotas** — existing config-driven limits (max files per suite, max file size, max files per request) continue to apply; a new per-request cap is introduced to bound batch size.
- **No DB schema changes** — files continue to be stored in the same per-suite layout in the DIAL bucket; only the upload-orchestration path changes.

### What alternatives have you considered?

- **Client-side parallel single-file uploads** — keep the server unchanged and let clients fan out N parallel HTTP calls. Rejected: pushes batch-size, retry, partial-failure, and limit-reconciliation logic onto every client; per-request overhead is still paid N times; limits can only be enforced after the fact.
- **ZIP archive upload + server-side extraction** — accept a single ZIP containing many files. Rejected as the primary mechanism: forces clients to package files first (especially awkward from a browser UI), obscures per-file validation errors, and overlaps with the existing ZIP **suite export/import** feature, which would be confusing to users; could be considered as an additional convenience later.
- **Streaming / chunked upload protocol** — adopt a resumable-upload protocol (tus-style) for large batches. Rejected for now: significantly higher implementation and operational cost, and does not directly address the "many small files" case which is the primary pain point.
- **Do nothing, document the workaround** — tell users to script sequential calls. Rejected: does not improve UX, does not reduce overhead, and leaves partial-failure handling unsolved.