Saving signals/images and exporting files gives no feedback on the destination; "Save to directory" cannot pick a folder

[PierreRaybaut]

Summary

A user testing DataLab-Web reported that saving files is confusing: "Save image" appears to do nothing visible (no indication of whether or where the file was saved), and "Save to directory" does not let the user choose a destination folder — it silently falls back to the browser's download mechanism.

Original user feedback

The only minor issue I had was with saving files.
I couldn't see if or where it would save files if I clicked "save image." It just gave me an option for a file extension, but i couldn't see if it saved the image on my computer or somewhere within the web frontend

It would save my files if i click "save to directory", but it wouldn't give me an option to which directory to save and would simply open a browser interface to save again. Not sure if that is intended to work like this, but at least I could save it.

Steps to reproduce

1. Open DataLab-Web and load or create a signal or image.
2. Select the object, then go to File > Save signal… (or Save image…).
3. Enter a file extension in the prompt and confirm.
4. Observe that nothing visible happens afterward — no confirmation, no indication of the destination folder.
5. Separately, go to File > Save to directory…, fill in the dialog, and confirm.
6. On a browser without the File System Access API (or when the picker is blocked), observe that files are downloaded one by one via the browser's own download UI, with no prior warning that folder selection is not possible.

Expected behavior

• Saving a file should let the user pick (or at least clearly see) the destination, mirroring the desktop application's save dialog as closely as the browser sandbox allows.
• When the browser cannot offer folder/file selection and downloads happen instead, the user should get a clear, visible confirmation of what was saved and where.

Actual behavior (before fix)

• "Save image"/"Save signal" only prompted for a file extension, then silently downloaded the file to the browser's default Downloads folder with no confirmation message.
• "Save to directory" used the File System Access directory picker only on Chromium-based browsers; elsewhere it fell back to individual downloads without warning the user beforehand.
• The native single-file "Save as…" picker (showSaveFilePicker) was not used anywhere in the codebase, even though it is available on Chromium-based browsers and would let users choose the destination folder and filename directly.

Root cause

• handleSaveFile in src/App.tsx used a one-line extension prompt followed by an <a download> click, with no user-facing feedback.
• handleSubmitSaveToDir in src/App.tsx used showDirectoryPicker when available, but fell back to per-file downloads silently when it was not.
• The app had a modal message system (useMessage in src/components/ConfirmDialog.tsx) but no lightweight, non-blocking notification suitable for this kind of confirmation.

Suggested / implemented fix

• Introduce a shared save helper (src/utils/saveFile.ts) that prefers the native showSaveFilePicker (Chromium) — letting the user pick the destination folder, filename and extension directly — and falls back to a browser download otherwise.
• Apply this helper to every save/export action: save signal/image, export metadata, export ROI (signal and image), save HDF5 workspace, plus macro/notebook/CSV/AI-assistant-conversation exports.
• Add a lightweight, non-modal toast notification (src/components/Toast.tsx) shown only on the download-fallback path, confirming the saved file name and that it went to the browser's Downloads folder.
• Warn the user before "Save to directory" falls back to individual downloads on browsers without a folder-picker API.