Mendelu/Prevent an admin from deleting their own account

[Kasinhou]

Backport of the UFAL self-delete guard from dtq-dev onto customer/mendelu — #1335 (the feature), #1357 (friendly rejection notification) and #1373 (tooltip clipped by the table).

What changes

• The EPeople registry and the EPerson form no longer offer delete for the currently authenticated user: the button renders disabled with a tooltip explaining why.
• Deleting a high-impact account now shows a contextual warning in the confirmation modal (submitter / administrator / both), via a new warningLabel input on ConfirmationModalComponent.
• If the backend still rejects a self-delete (400), the UI shows the friendly "you cannot delete your own account" notification instead of a generic failure.
• Shared logic lives in the new EPersonDeleteGuardService so the registry and the form stay in sync.
• New en/cs i18n keys for the notification and the three warnings.

Branch-specific notes
Translated (not cherry-picked): DSpace 9.1 uses standalone components and @if control flow, so there is no AccessControlModule to register the service in — EPersonDeleteGuardService is providedIn: 'root' here, and NgbTooltipModule + BtnDisabledDirective were added to the two components' imports.

Verified locally (Node 22): ng test --include='src/app/access-control/epeople-registry/**/*.spec.ts' and --include='src/app/shared/confirmation-modal/**/*.spec.ts' all green; eslint on the changed files reports 0 errors.

Backend counterpart: dataquest-dev/DSpace#1401 — the two must ship together.

Refs dataquest-dev/dspace-customers#855

---

How this was verified

Manual — on a live instance (JCU 9.3 pair)

Throwaway stack: backend built from the paired branch jcu/be-forbid-admin-self-delete (REST on :8091,
own DB / Solr), frontend served from the branch under test, logged in as an administrator.

	Result
Before (base branch)	The Delete button on the administrator's own row in Access Control → EPeople is enabled and clickable. Driving that same delete through the REST API returned 204 and the account was gone (404) — the bug in issue #855, reproduced.
After (this change)	The own row's Delete button is disabled and carries the tooltip "You cannot delete your own EPerson account.", rendered above the table without being clipped (the container="body" part of #1373).
Regression	Deleting a different EPerson still works end to end: confirmation modal → Delete → the row disappears.
Other rows	Unaffected — still enabled.

Automated

Locally on this branch (Node 22):
ng test --include='src/app/access-control/epeople-registry/**/*.spec.ts' → 43 tests, 0 failures;
--include='src/app/shared/confirmation-modal/**/*.spec.ts' → 11 tests, 0 failures;
eslint on the changed files → 0 errors.
The CI tests job runs lint plus the full unit suite on this PR.

The live run was on JCU 9.3 (DSpace 9.3). Mendelu (9.1) shares eperson-delete-guard.service.ts and both templates byte-identically with the exercised branch; only the two *.component.ts files differ, and only where the branch bases already differed (Angular 18 vs 20). Not exercised live.

---

Follow-up after Copilot review

Copilot flagged that the else branch of the registry delete handler passed
notification.deleted.success to notificationsService.error(...), so any delete
failure other than a self-delete rendered a red toast reading "Successfully deleted
EPerson: """ — with an empty name, and with {{restResponse.errorMessage}} never
filled in.

Valid finding, and not a new idea: dtq-dev already fixes this in the very commit this
PR backports (07957d83b1, UFAL port of dspace-angular#1335). The hunk was missed when
the change was translated to the 9.x component. Fixed in a follow-up commit — the branch
now matches dtq-dev:

this.notificationsService.error(this.translateService.get(this.labelPrefix + 'notification.deleted.failure', {
  name: this.dsoNameService.getName(ePerson),
  id: ePerson.id,
  statusCode: restResponse.statusCode,
  errorMessage: restResponse.errorMessage,
  restResponse,
}));

Only the two 9.x branches (mendelu, jcu) needed this — the 7.6.1/7.6.5 branches took
the hunk whole during the cherry-pick and already used the failure key, and TUL (7.5)
never used the key at all (it builds the message inline). Unit tests re-run after the
change and still green.

Live UI screenshots

Captured live in a browser (9.1 FE against a DSpace 9.3 backend): logged in as an administrator, opened
Access Control → EPeople. The admin's own row is the first one.

Before — the own row's Delete button is enabled/clickable (the bug).

After — the own row's Delete button is disabled and shows the tooltip "You cannot delete your own EPerson account."; other rows stay enabled.