ZCU-DATA/Prevent an admin from deleting their own account

[Kasinhou]

Backport of the UFAL self-delete guard from dtq-dev onto customer/zcu-data — #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
Cherry-picked, then adapted: 7.6.1 has no dsBtnDisabled directive, so the disabled delete button uses the native [disabled] binding (specs assert nativeElement.disabled instead of aria-disabled). activeEPerson$ was introduced on the form component, which this branch did not have.

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#1398 — 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' → 55 tests, 0 failures;
--include='src/app/shared/confirmation-modal/**/*.spec.ts' → 13 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 the JCU 9.3 pair. The three 7.6.1 branches — zcu-pub, zcu-data, sav — carry byte-identical source files for this change (all five of them; only the i18n files differ between the three), so this verification applies equally to all three. The 7.6.1 UI itself was not exercised in a browser; its behaviour is covered by the unit tests below, which assert the same DOM outcome (button disabled, modal not opened, notification shown).

Live UI screenshots

Captured live in a browser (7.6.1 FE against a genuine DSpace 7.6.5 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.