Introduce CloudBeaver password change UI

**Is your feature request related to a problem? Please describe.**

CloudBeaver exposes no UI to change the password of the connected database user. Two consequences:

1. Expired DB credentials (Oracle `ORA-28001`, PostgreSQL `SQLSTATE 28P01` with `password expired`) block login. The user has no in-app path to set a new password and depends on an administrator.
2. Routine DB-side password rotation forces a switch to DBeaver desktop or a native client (`sqlplus`, `psql`).

**Describe the solution you'd like**

Add a per-connection "Change database password" action, mirroring DBeaver desktop:

1. Context-menu entry on a connection: `Security > Change database password`.
2. Dialog collects current password, new password, and repeat. Server applies the configured password policy.
3. Backend GraphQL mutation invokes the per-dialect `SQLDialectChangePasswordHandler` reachable from the embedded DBeaver core bundles.
4. Expired-password login variant applies only to Oracle (`ORA-28001`), MySQL (`ER_MUST_CHANGE_PASSWORD` 1820), and SQL Server (error 18488). The login dialog offers an inline "set new password" flow using the driver's native change-at-login mechanism for those three engines. Postgres-family (PostgreSQL, Greenplum, CockroachDB), Exasol, and Vertica have no equivalent driver-level flow. On those engines, users change the password from the normal "Change database password" action while credentials remain valid.
5. Gate the action behind three AND-combined conditions, each mapped to an existing CloudBeaver policy dimension. The action appears only when all three are true:
- Server flag `dbUserPasswordChangeEnabled` or similar, likely added to `CBAppConfig` next to `publicCredentialsSaveEnabled` / `enableReverseProxyAuth`. Default `false`.
- Team permission `PERMISSION_DB_USER_PASSWORD_CHANGE` or similar, likely added to `DBWConstants`, enforced via `@WebAction(requirePermissions = ...)` on the mutation.
- Per-connection field `configuration.dbUserPasswordChangeAllowed` or similar on the data-source entry. Default `false`.
6. The mutation writes an audit-log entry unconditionally, independent of the gates.

Compatibility of the change was verified against the databases DBeaver desktop already supports for this action: Oracle, PostgreSQL, MySQL, SQL Server, Greenplum, Cockroach, Exasol, Vertica.

**Describe alternatives you've considered**

- Redirect users to DBeaver desktop or a DBA. This forces context switch and undermines CloudBeaver as a single-tab SQL entry point.
- Admin-driven password reset outside the tool. This exposes user credentials to admins and does not resolve the expired-password login failure.

**Additional context**

- Per-dialect `SQLDialectChangePasswordHandler` classes live in DBeaver core. CloudBeaver server bundles already declare `Require-Bundle` on `org.jkiss.dbeaver.*`, so the handlers are reachable without new dependencies.
- The existing `ChangePassword.tsx` under `webapp/packages/plugin-user-profile/src/UserProfileForm/UserAuthenticationPart/` targets the CloudBeaver-local user (via `UserInfoResource.updateLocalPassword`) and is not applicable to the connected database user.
- Related, closed: #361 (CloudBeaver-local user, different scope).
- The three gate dimensions cover mixed deployments where the same user connects to PAM-owned, Vault-owned, Kerberos `IDENTIFIED EXTERNALLY`, CMU `IDENTIFIED GLOBALLY`, and personally-owned accounts in one CloudBeaver instance. Each of those connection classes has different rules for who may change the password, so a single-axis gate (flag-only or permission-only) does not suffice.
- Per-database credential-lifecycle notes:
- Oracle: `IDENTIFIED BY new REPLACE old` is REQUIRED when the caller's own password is expired.
- MySQL: `disconnectOnExpiredPasswords=false` MUST be set on the JDBC URL to enable Connector/J sandbox mode for the expired-login variant.
- SQL Server: the expired-login variant MUST use the Microsoft JDBC driver `SQLServerConnection.setChangePassword` API.
- Exasol: expiry uses a server-side grace period (`GRACE_DAYS`). Password change during grace is the only supported path. No driver handshake.
- Vertica: the DEFAULT profile carries `PASSWORD_LIFE_TIME = UNLIMITED`. Expiry applies only when a non-default profile is assigned.
- PostgreSQL, Greenplum, CockroachDB: expiry is `VALID UNTIL ` per role. Expired credentials fail authentication with no server-mediated recovery. Users MUST rotate before `VALID UNTIL` elapses.