149 support importing multiple collections at once

[matstech]

Summary

This PR introduces batch collection import for all four supported formats (Postman, Bruno, OpenAPI/Swagger, and Solo), replacing the old single-file import API with a batch-first API on both the backend and the frontend.

Closes: #149

Description

Backend

Four new public App methods replace the old single-import collection methods:

func (a *App) ImportPostmanCollections(paths []string) (collection.BatchImportResult, error)
func (a *App) ImportBrunoCollections(paths []string)  (collection.BatchImportResult, error)
func (a *App) ImportOpenAPICollections(paths []string) (collection.BatchImportResult, error)
func (a *App) ImportSoloCollections(paths []string)   (collection.BatchImportResult, error)

The old single-file methods (ImportPostmanCollection, ImportBrunoCollection, ImportOpenAPICollection, ImportSoloCollection) have been removed from the Wails surface.

Batch orchestration lives in internal/collection/batch_import.go. Each batch run:

• parses/imports concurrently with a bounded worker limit (maxConcurrentCollectionImports = 4)
• preserves input order in results
• saves successfully imported collections serially via UpdateCollection
• never fails fast on per-item errors — one bad path does not abort the others

A new SelectFiles method was added alongside the existing SelectFile and SelectDirectory:

func (a *App) SelectFiles(title, patterns, displayName string) ([]string, error)

The Bruno importer was also fixed in this PR:

• params:query and params:path DSL sections are now parsed correctly alongside the older query section
• Query params already present in the URL are no longer duplicated when they also appear in params:query
• Path params in params:path are substituted directly into the URL

Frontend

collectionImportStore.svelte.ts was migrated to the batch APIs. The pending import state changed from a single path: string to paths: string[]. Postman, OpenAPI, and Solo use the new multi-file picker; Bruno keeps the single-directory picker (multi-directory Bruno import is supported through drag-and-drop).

After a batch completes, a summary notification is shown:

• All succeeded → N collections imported
• Partial success → N imported, M failed (first few per-item errors shown as separate toasts)
• All failed → Failed to import N collections

LocalImportPane.svelte was updated so the onImport callback receives droppedPaths?: string[] instead of a single optional path. The display now shows the full path for one source and N sources selected for multiple. The component remains generic and shared with environment imports.

EnvironmentManager.svelte was updated to stay compatible with the new LocalImportPane callback shape while preserving single-source environment import behavior (paths?.[0]). No batch environment import is introduced.

CollectionList.svelte wires the new store shape: import disabled state checks paths.length, drag-and-drop forwards all dropped paths to the store, and the old Solo overwrite modal was removed (Solo batch always overwrites).

The environment manager modal was also fixed: the modal no longer opens fullscreen (was using fullscreen + size="none"); it now uses size="xl" with a fixed body height, matching the Settings modal layout.

Accepted limitations

• Bruno multi-directory import is supported through drag-and-drop only. OpenDirectoryDialog in Wails returns a single path; there is no multi-directory picker equivalent.
• Batch progress is summary-only. No real-time per-item progress events are emitted.
• BasePath and Servers are not exposed in the batch result DTO. The OpenAPI importer already uses this metadata internally to compute the imported collection's baseUrl variable; the frontend only needs per-item warnings.
• Solo batch import always overwrites existing same-name collections.

Breaking Changes

The following public App methods have been removed from the Wails surface:

• ImportPostmanCollection(path string) error
• ImportBrunoCollection(path string) error
• ImportOpenAPICollection(path string) (OpenAPIImportCollectionResult, error)
• ImportSoloCollection(path string, overwrite bool) error
• OpenAPIImportCollectionResult type

Callers should use the new batch methods, passing a one-item path slice for single-source imports.

Tests performed 🧪

• Backend unit tests for CollectionManager.ImportBatch: global errors (nil manager, empty paths), per-item failures (empty path string, import error, nil collection, save error), result ordering, warnings propagation, mixed success/failure
• Bruno importer tests: params:query, params:path, and URL deduplication coverage using a real Bruno collection fixture
• go test ./... passes
• go build ./... passes
• cd frontend && npm run format passes
• cd frontend && npm run check passes (0 errors, 0 warnings)
• cd frontend && npm run lint passes
• cd frontend && npm run build passes
• Manual QA: multi-file picker (Postman, OpenAPI, Solo) selects and imports multiple files
• Manual QA: drag-and-drop of multiple Bruno directories imports all directories
• Manual QA: partial failure shows correct summary toast and per-item error toasts
• Manual QA: environment import still works after LocalImportPane callback shape change
• Manual QA: environment manager modal opens correctly (no longer fullscreen)

[speziato]

It looks good code-wise, but I want to discuss a bit the "implicit overwrite" approach.

Are we sure we want to implicitly overwrite an existing collection when importing? I get that the flow could get complicated, but I would not assume that users want to overwrite things.

An idea could be to place a "Overwrite existing collections" checkbox somewhere: if checked, it behaves as currently coded, otherwise we could present a simple modal with the list of ignored collections at the end of the import process.

What do you think?

[matstech]

It looks good code-wise, but I want to discuss a bit the "implicit overwrite" approach.

Are we sure we want to implicitly overwrite an existing collection when importing? I get that the flow could get complicated, but I would not assume that users want to overwrite things.

An idea could be to place a "Overwrite existing collections" checkbox somewhere: if checked, it behaves as currently coded, otherwise we could present a simple modal with the list of ignored collections at the end of the import process.

What do you think?

Let me just note what we discussed in the call: this is a great idea to implement. Anyway we've refined this concept and in the next batch of commits, I'll introduce a way to inspect all errors occured during batch import. For each collection you will be able to choose whether or not to overwrite (this will then be reported in a table or something similar).