Show the uploaded file name in submission upload notifications

[milanmajchrak]

Description

Drop three files into a submission and you get three identical "Upload successful" toasts. If one of them fails, there's no way to tell which. This makes each notification name its file. When we don't have a name to show, you get the old generic message, same as before.

Instructions for Reviewers

What changed:

• ds-uploader gets a second output, onCompleteItemWithFile, carrying { response, fileName? }. The old onCompleteItem still fires first and still emits the bare response, so the three other places using the uploader don't notice anything.
• onUploadError is typed as UploaderError now instead of any, and the upload notification keys all moved into one small getNotificationContent() helper.
• Two new keys in en.json5. Locales that don't have them yet fall back to the generic message instead of printing a raw submission.sections.upload.* key — that's what the default interpolate param is doing.

To try it: drop two or three files into the Upload section and check each toast names the right one. For the size-limit path you need dspace.upload.max configured, otherwise the feature is simply off and the test tells you nothing.

Before, both files give you the same message:

After:

Checklist

• Created against main — no, this one is a backport onto dtq-dev.
• Small — 51 lines of actual code across 4 files, the rest is specs and i18n.
• Follows our coding conventions.
• Passes ESLint — green in CI.
• No circular dependencies — green in CI.
• TypeDoc on everything new.
• Specs — 24 new ones. CI went from 5467 to 5491 passing, nothing else moved.
• Accessibility — the notification component isn't touched, so it's the same role="alert" region and the same escaped rendering path, only the text differs. I haven't put a screen reader on it.
• i18n keys, no hardcoded English.
• How to test it — above.
• No new dependencies.
• Nothing new to document.

_{Written with some help from Claude Code.}

[lgeggleston]

@milanmajchrak thanks for submitting this improvement to usability!

[MMilosz]

I ran the changes locally without diving into the code. Overall, the functionality works very well. What I verified:

• Properly uses filename received from backend: when uploading file.txt and re-uploading it, backend names the duplicate file (1).txt and the exact same name is shown in notification
• Batch uploads work as expected
• Error handling works properly
• Non-Latin alphabet filenames display correctly
• Changing to other language (without the new i18n key) shows generic notification
• Poisonous filenames (XSS attempts, unusual encodings, control characters) don't corrupt the UI or cause unexpected behavior
• Missing filenames are handled gracefully

One concern from me: each file upload now triggers 4 additional API requests (see screenshot), which can impact performance especially for batch uploads in peak hours.

Before

Upload completes with a single 201 response.

This PR

After a 201 response, upload fires another 4 requests (I see that the first 201 response already returns filename, in this case it's core-js-banners, without extension).

@milanmajchrak is it possible there's some component re-rendering happening? Or is it intentional?

Other screenshots

All looks good, I'm sharing some screenshots of the different cases tested