Api: Add $archive-import zip enumeration

[losolio]

ImportService now opens the uploaded stream as a ZipArchive, emits a Progress event per entry plus an overall Completed event on the operations hub, and surfaces invalid zip content as a clean Error event.

Per-entry handling routes through an IngestEntryAsync stub that a later slice will replace with FHIR resource parsing and ingestion. Entry names are truncated before reaching hub events.

[Copilot]

Pull request overview

This PR updates Ignis.Api’s $archive-import operation to open an uploaded zip stream, enumerate entries, and publish progress/completion/error events via the operations SignalR hub, with corresponding integration tests validating the hub events.

Changes:

• Replace the import service stub with zip archive enumeration + per-entry Progress events and a final Completed (or Error on invalid zip) event.
• Update the import controller to pass the uploaded file stream into the import service and clarify the endpoint’s “enumeration-only” behavior in docs.
• Add integration tests that upload a valid/invalid zip and assert expected hub events are published.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
tests/Ignis.Api.Tests/ImportControllerTests.cs	Adds SignalR-based integration tests for valid zip enumeration and invalid zip error reporting.
src/Ignis.Api/Services/Import/ImportService.cs	Implements zip enumeration with progress/completed/error notifications and entry-name truncation.
src/Ignis.Api/Services/Import/IImportService.cs	Updates the import API to accept an archive Stream and documents the new slice behavior.
src/Ignis.Api/Controllers/ImportController.cs	Wires the uploaded file stream into the new import method and updates endpoint documentation.

Comments suppressed due to low confidence (1)

tests/Ignis.Api.Tests/ImportControllerTests.cs:131

• The hub callbacks ignore the operationId argument and append to List<string> from the SignalR callback thread. This can make the test flaky (picking up messages from other operations) and List<T> is not thread-safe. Consider filtering messages by the operation id returned in the HTTP OperationOutcome, and using a thread-safe collection (or locking) for progressMessages.

        var progressMessages = new List<string>();
        var completedTcs = new TaskCompletionSource<string>();
        hub.On<Guid, string, OperationProgress?>(
            OperationProgressHubMethods.Progress,
            (_, msg, _) => progressMessages.Add(msg));
        hub.On<Guid, string>(
            OperationProgressHubMethods.Completed,
            (_, msg) => completedTcs.TrySetResult(msg));

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[losolio]

Thanks for pointing this out. I think we should before merging this establish a background worker, and will in a separate PR do the plumbing for a background worker.