Updated the documentation for the `user.update` permission to explicitly state it is an administrator-level permission, distinguishing it from `user.update_owned`.

Removed `Permissions.userCreate` and `Permissions.userDelete` from the `_dashboardAdminPermissions` set. This change enforces the rule that administrators can only update users through the generic data API, while creation and deletion are handled exclusively by the authentication service.

Updated the `ModelConfig` for the `user` model to mark `POST` (create) and `DELETE` operations as `RequiredPermissionType.unsupported`. This change enforces that user lifecycle management is handled exclusively by the authentication service, not the generic data endpoint. Added comments to clarify the update logic flow.

Removed the 'user' model from the item creators and deleters maps, enforcing that user creation and deletion are handled exclusively by the authentication service.
Completely rewrote the custom updater for the 'user' model to be secure and architecturally sound. The new logic:
- Enforces that administrators can only update `appRole` and `dashboardRole`.
- Enforces that regular users can only update their own `feedDecoratorStatus`.
- Rejects attempts to update any other fields via this endpoint.
- Reads the pre-fetched user object and uses `copyWith` to apply only the allowed changes, creating a full, valid `User` object for the repository's `update` method. This resolves the previous partial update issue and aligns with the `DataRepository<T>` contract.

Added two new methods to `AuthService` to handle user email changes securely:
- `initiateEmailUpdate`: Checks if the new email is available, then generates and sends a verification code to the new address.
- `completeEmailUpdate`: Verifies the provided code and, upon success, updates the user's email in the database.
This ensures that a user must prove ownership of the new email address before the change is finalized, enhancing account security.

Refactored the custom user updater to correctly handle a full `User` object in the request body, aligning with the `DataRepository` contract and fixing the `500` error seen by the client.
The new logic performs a state comparison:
- It deserializes the incoming request body into a `User` object.
- It compares this object against the pre-fetched user from the database to identify which fields have changed.
- It verifies that only permitted fields (`appRole`/`dashboardRole` for admins, `feedDecoratorStatus` for users) have been modified.
- If validation passes, it proceeds with the update using the full `User` object from the request.
This fixes the bug while maintaining security and architectural consistency.

@gemini-code-assist gemini-code-assist bot left a comment