LCFS - Show full impact and notify users about role and status changes

**Description:**

Changing a user’s role or account status can affect their access, notification subscriptions and assigned work.

When a role is removed or a user is deactivated:

* Notifications tied to that role will no longer be received.
* Existing notification subscriptions may be removed.
* Previous preferences may not be restored if the role is added again.
* Reports or applications may remain assigned to a user who can no longer access them.

Before confirmation, all known impacts must be clearly described. After the change, the affected user must receive a mandatory email explaining what changed, similar to security emails sent for important banking or account changes.

This email must be sent independently of the configurable notification-subscription system. A user should not miss the change email because their subscriptions were removed by the same action.

**Wireframe:** [To discuss whether it’s needed]

**Purpose and benefit to user:**

* Prevent unexpected loss of notification preferences.
* Reduce missed role-based notifications.
* Identify assigned work requiring attention.
* Make important account changes transparent.
* Alert users to unexpected or unauthorized changes.
* Provide administrators with a clear review before confirmation.

## Suggestions

### 1. Impact summary before confirmation

Show all material impacts, including:

* Current → new role/status
* Roles being added or removed
* Access being gained or lost
* Notification subscriptions being added, removed, preserved or restored
* Notifications the user will start or stop receiving
* Notification-email changes
* Associated reports, CI applications or other assigned work
* Whether the change is reversible
* Any follow-up action required, such as reassignment

### 2. Preserve notification preferences

Notification preferences should be preserved by role rather than permanently deleted.

If a role is restored, its previous preferences should also be restored. If restoration is not possible, the administrator and affected user must be told which settings were removed and need to be configured again.

Note: When a role changes, not all subscriptions tied to the new role are assigned.
** Confirm whether this is intended or a bug. **

### 3. Mandatory change email

Send a direct email for:

* Role added or removed
* User activated or deactivated
* Notification email changed
* Notification preferences reset or restored

The email should include:

* What changed
* Who made the change
* Date and time
* Access affected
* Notifications added or removed
* Assigned-work impact
* Required next steps
* Where to report an unexpected change

When the notification email changes, send the alert to both the previous and new addresses where possible.

Sensitive record details should remain inside LCFS; the email can provide counts and a secure link to view them.

### 4. Assigned-work impact

If the user has associated work, show the affected record types and counts. Deactivation must not silently leave work without an active owner.

Automatic reassignment is outside this ticket, but the administrator should be warned and directed to the affected records.

## Acceptance Criteria

* Given a role or status change has a material impact, when it is submitted, then a complete impact summary is shown before anything is updated.
* Given subscriptions are affected, then the summary identifies which notifications will be added, removed, preserved or restored.
* Given a notification is tied to a removed role, then the summary explains that the user will no longer receive it.
* Given the user has assigned work, then the summary shows the affected record types and counts.
* Given a role is removed, then its notification preferences are preserved.
* Given the role is restored, then its previous preferences are restored.
* Given the change succeeds, then the affected user receives a mandatory email containing all material impacts.
* Given the user’s notification email changes, then the previous and new addresses are notified where possible.
* Given subscriptions are removed, then the mandatory change email is still sent independently of those subscriptions.
* Given email delivery fails, then the account change is not hidden and the administrator is informed of the delivery failure.

## Development Checklist

* Add the impact preview and confirmation.
* Calculate all access, notification and assignment impacts.
* Preserve and restore role-specific preferences.
* Add mandatory emails outside the configurable notification system.
* Add email templates for role, status and notification-setting changes.
* Notify old and new email addresses when the destination changes.
* Add post-change summary and email-delivery status.
* Cover role removal/restoration, deactivation/reactivation and failure cases.

## Future high-impact notification candidates

The same mandatory-notification approach should be considered for other high-impact areas that need to be identified.

**Notes:**

There is no general security-style notification for high-impact account changes. This new email must therefore be treated as a mandatory service message and must not depend on the user’s configurable subscriptions.

The issue names no files or tests; start by tracing the role/status-change entry points and the notification-subscription, assigned-work, and email-delivery flows. Resolve the open wireframe question and confirm whether subscriptions tied to a newly added role should be assigned. Done means the impact preview, preference preservation, independent mandatory emails, delivery failures, and acceptance scenarios are covered.

Written by the indexing model from the issue text.