Replace the translated-string size-limit discriminator with a locale-independent marker

[milanmajchrak]

Follow-up to #1411. Not a bug today, and explicitly out of scope there — recording it so it is not rediscovered the hard way.

SubmissionUploadFilesComponent.onUploadError decides whether an upload failure was the client-side size-limit rejection by comparing the emitted response against a translated string:

const errorMessageUploadLimit = this.translate.instant('submission.sections.upload.upload-failed.size-limit-exceeded');
const isFileSizeLimitError = error?.response === errorMessageUploadLimit;

The uploader produced that same string with the same one-argument translate.instant(key) call, so today the === holds in every locale. But it is brittle in a way nothing catches:

• adding any interpolation param at either site makes the comparison silently false — no compile error, no failing spec, and eight live customers quietly lose their only actionable oversized-file message;
• it depends on the two instant() calls resolving in the same locale at the same moment.

#1411 pins the current behaviour with specs and documents the constraint in a TypeDoc block, but does not change the mechanism.

Proposed fix: replace the translated-string discriminator with a locale-independent marker — either response: '<the i18n key>' (not its translation) or an optional sizeLimitExceeded: true on the emitted UploaderError. Verified safe in principle: no other onUploadError consumer on dtq-dev renders error.response.

Related, also deliberately unfixed in #1411:

• MyDSpace's handler branches only on error.status === 422 and so ignores the size-limit emit's status: 400 — it has no size-limit message at all;
• a locale missing submission.sections.upload.upload-failed.size-limit-exceeded already renders the raw dotted key in that toast.

[milanmajchrak]

Closing — filed outside the agreed scope of #1411. The content is preserved in that PR's working notes if we want to re-file it deliberately later.