Reader role: an administrator made on 2.2 through the user page or POST /admin/users holds admin alone, so an IdP or upstream demotion leaves them Roles only #812

Problem

#792 (#810) gave the built-in reader role to every administrator that migration 0013 finds, so one whom the identity provider or upstream later demotes stays a reader. docs/changes/2.2.0/733.upgrade.md promises the same for accounts made after the upgrade: such an admin "stays a reader, as an account created after the upgrade does".

Accounts made admin on 2.2 through the admin UI or API do not get reader:

• Switching an account to Admin on its page. UserAccess (web/src/routes/admin/users/Edit.tsx:244-253) assigns admin, then unassigns every other level role in LEVEL_ROLES (admin, writer, reader). That removes reader.
• Creating an admin. Admin → Users → New user with access level Admin (web/src/routes/admin/users/Create.tsx:82), or POST /admin/users with "role": "admin", goes through insert_with_role (crates/server/src/admin/users.rs:731), which assigns admin only.

A demotion removes admin and nothing else, so the account is left with no built-in role:

• OIDC: crates/core/src/oidc/mod.rs:370, when the realm maps admin groups or an admin claim.
• Credential forwarding: crates/core/src/auth/chain.rs:351, when the realm has admin_group.
• Both call authz_dao::sync_admin_role(.., false) (crates/db/src/authz_dao.rs:380).

An OIDC account that the IdP provisions straight into admin does hold reader (provision_oidc_user assigns new_account_access first), so after a demotion it is a reader. The two paths disagree.

Scenario

1. A credential-forwarding realm (a Nexus migration) has admin_group.
2. An administrator creates the account of a Nexus admin under Admin → Users → New user with access level Admin. Or they switch an existing reader to Admin on its page.
3. Later the upstream drops the person from the admin group. On their next sign-in sync_admin_role(false) removes admin.
4. The account now holds no built-in role. Admin → Users shows it as Roles only, and with anonymous access off every repository answers 403 or 404.

Nobody gains access. The account loses all of its read access instead.

Expected

An administrator holds reader as well, however they became one, so that a demotion leaves a reader. Either of these would do it:

• Keep reader next to admin: the user page does not unassign it, and POST /admin/users with role: admin also assigns reader to user accounts (not to service accounts, which stay Roles only).
• Or have sync_admin_role(false) assign the realm's new_account_access role when it removes admin.

Tests: an account switched to Admin on the user page, and one created with "role": "admin", is a reader after an OIDC or upstream demotion.

New with #733 (#734). #792 fixed only the accounts migration 0013 finds. Found in the 2.2.0 release review.