feat(import): single + batch (array-in-file + multi-file) upload for ODCS & ODPS (#855)

[larsgeorge-db]

Closes #855.

Unifies contract (ODCS) and product (ODPS) upload so both entities accept all three input shapes in one operation, reported via a truthful summary:

1. Single entity (one object in one file).
2. Array-in-file — multiple entities in one YAML/JSON file (parity fix for contracts; products already did this).
3. Multiple files selected at once — each parsed, all entities aggregated.

Per the agreed design, this PR is the plumbing foundation for the stacked siblings #851 (domain reconciliation) and #853 (UUID-as-PK). Reconciliation toggles and duplicate-id handling land in those PRs.

Backend

• New shared models/import_results.py: BatchImportResult + ImportItemResult. The skipped status and source_id/entity_id provenance fields are part of the contract from the start so feat(import): adopt ODCS/ODPS domain element on YAML import and round-trip #851/feat(import): adopt YAML entity id (UUID) on ODCS/ODPS import to preserve links #853 can populate them without another response-shape change.
• Contracts: parse_uploaded_entities (array-in-file) + create_contracts_from_files. /data-contracts/upload now takes List[UploadFile]; /data-contracts/odcs/import accepts an object or an array. Both return BatchImportResult.
• Products: extracted _parse_products_content, added create_products_from_files. /data-products/upload takes List[UploadFile] and returns BatchImportResult (was List[DataProduct] + 422-on-partial). Also fixed a latent bug where json.JSONDecodeError was referenced in an except clause before json was imported — only reachable now that non-JSON files flow through the parser.
• Per-entity failures are recorded as failed items and never abort the batch (each entity commits in its own transaction). Truthful "N created, M skipped, K failed" report, same pattern as the demo-data loader.

Frontend

• Shared types/import-results.ts (BatchImportResult + summarizeImport).
• data-products and data-contracts views send every selected file under files (multi-file input / dropzone multiple), and render the truthful summary + first per-entity failures. The contract JSON-paste flow also surfaces the summary.

API contract change (intentional)

• POST /api/data-contracts/upload: field file → files (List[UploadFile]); response is BatchImportResult (200) instead of a single DataContractRead.
• POST /api/data-products/upload: field file → files; response is BatchImportResult (200) instead of List[DataProduct] (201 / 422-on-partial).
• POST /api/data-contracts/odcs/import: body may now be an object or an array; returns BatchImportResult.

Tests

• New manager-level unit tests for both entities: array-in-file, multi-file aggregation, bad-entity-continues-batch, unsupported/unparseable file, sourceId preservation (10 tests, all green).
• Updated the contract upload/import integration tests to the new files/BatchImportResult contract.
• Note: 6 pre-existing failures in test_data_products_manager.py (duplicate-id / validation-error assertions) exist on development independently of this change — verified by re-running on a clean tree.

This pull request and its description were written by Isaac.

[mvkonchits-db]

Requesting changes on upload hardening. #862, #863 and #930 all build on this, so it is worth getting right here. Items marked (verified) I confirmed in the code.

Must fix:

1. (verified) No file-count or size limits on either upload route. Every file is read fully into memory (await f.read()). PyYAML safe_load also does not limit alias expansion, so a small alias-heavy file can balloon memory. Please cap file count and bytes per file and in total.
2. (verified) data_contracts_routes.py: all files are decoded with .decode('utf-8') before per-file handling. One non-UTF-8 file returns HTTP 500 and imports nothing, which contradicts "one bad entity never aborts the batch". Decode inside the per-file handling and record a failed item.
3. (verified) Raw exception text is returned to clients, both as per-item message and in the 500 detail (f"{type(e).__name__}: {e}"). That can expose SQL or internal detail. Log it, return a generic message.

Should fix:
4. (reported, not traced by me) Uploading an empty ODPS array appears to render "0 imported successfully" in the UI, while the contract path classifies an empty array as failed.
5. Tests stub the post-commit index update and pass pre-decoded text, so the route-level invalid-UTF-8 case is untested.

Note for the stack: #862 and #863 extend both create_*_from_files signatures and rely on skipped, source_id, entity_id and created_ids. #930 depends on the multipart field name files and the BatchImportResult / summarizeImport contract, so those should be treated as stable.

[mvkonchits-db]

Re-reviewed dccf7c5 against my earlier items. All four are addressed, and I checked them in the code, not just the commit message.

• Upload caps: read_uploads_capped (50 files, 5 MiB per file, 25 MiB total) is used by both upload routes and reads one byte past the per-file cap. A breach is a 413, and the existing except HTTPException: raise lets it through. Unit and route tests added.
• Decode per file: a non-UTF-8 file is now a failed item and the batch continues.
• Error text: the per-item messages and the three 500 details are generic now, with the full detail logged.
• Empty ODPS array: now a failed item, with a test.

CI is green on the development base.

Correction to my earlier note: I said a small alias-heavy YAML file could balloon memory at load time. I tested it, and PyYAML safe_load shares references, so a 546-byte alias bomb loads in about 1 ms. It only blows up if later code walks, copies or serializes the structure. I did not trace whether the import path does that, and the same exposure exists on the single-file path already on development, so it is not a blocker here.

Non-blocking follow-ups:

• The paste route import_odcs_json takes Body(...) with no size cap.
• Other detail=str(e) responses in these route files predate this PR and are out of scope.

Approving. #862, #863 and #930 depend on the files field name and the BatchImportResult contract, so please keep those stable.