Gray out username, name, and email when self-service edits are forbidden

## What

when AUTHENTIK_DEFAULT_USER_CHANGE_* forbids edits, username/name/email fields should be readonly/grayed out instead of submitting and erroring. Also: readonly prompt fields: “allow blank” on a read-only field still fails, same class as grayed-out self-service fields.

## Want

- When AUTHENTIK_DEFAULT_USER_CHANGE_* forbids edits, username/name/email fields should be readonly/grayed out instead of submitting
- Related readonly prompt fields: “allow blank” on a read-only field still fails, same class as grayed-out self-service fields

## Ideas this came from

- [#7790 Selfservice fields (change username, name, email) should be grayed out when changing is prohibited](https://github.com/goauthentik/authentik/issues/7790) — When opening the user details page the input fields can always be changed, even if doing so is prohibited by the AUTHENTIKDEFAULTUSERCHANGE{NAME,EMAIL,USERNAME}
- [#13836 Make username field readonly when changing username is disabled](https://github.com/goauthentik/authentik/issues/13836) — Even when users are forbidden to change their username, the "username" type prompt field is editable and submittable, resulting in an error message telling you
- [#18899 Authentik 2025.10.3 - Read-only field - Is 'allow blank' really working?](https://github.com/goauthentik/authentik/issues/18899) — This morning I have seen the release of Authentik 2025.10.3. I have seen this line within the changelog: That interests me as I need a read-only field which acc

No files or tests are named. Start by tracing the self-service username, name, and email fields and the readonly prompt-field handling, using AUTHENTIK_DEFAULT_USER_CHANGE_* as the behavior entry point. Done means forbidden self-service fields are readonly/grayed out and readonly prompt fields with “allow blank” no longer submit and fail.

Written by the indexing model from the issue text.