[Feature] Durable ACCOUNT_LOCK / ACCOUNT_UNLOCK for user accounts

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues.

### Description

`CREATE USER ... ACCOUNT_LOCK` and `ALTER USER ... ACCOUNT_LOCK | ACCOUNT_UNLOCK` are in the grammar and in `AlterUserOpType`, but today the lock half does nothing:

- `CREATE USER ... ACCOUNT_LOCK` parses and is silently ignored. `LogicalPlanBuilder` stores the option in `PasswordOptions.accountUnlocked`, and nothing on the create path reads it, so the new user logs in normally.
- `ALTER USER ... ACCOUNT_LOCK` is refused at analysis with "Not support lock account now" (`AlterUserInfo.validate`).
- `ALTER USER ... ACCOUNT_UNLOCK` works, but only resets the failed-login counter.

The only lock Doris has is the FAILED_LOGIN_ATTEMPTS / PASSWORD_LOCK_TIME one, and that one is not durable: `FailedLoginPolicy.failedLoginCounter` and `lockTime` are deliberately not persisted and `onFailedLogin` writes no edit log, so each FE keeps its own counter, and a restart or a master switch clears the lock. There is no way for an administrator to lock an account so that it stays locked cluster-wide (offboarding, incident response, accounts that exist only as proxy targets).

### Use case

Administrators need a durable, MySQL-compatible way to stop an account from authenticating without dropping it (its grants, roles and policies must survive) and without knowing or changing its password: `ALTER USER 'u'@'%' ACCOUNT_LOCK`, later `ACCOUNT_UNLOCK`; `CREATE USER ... ACCOUNT_LOCK` for accounts that should never log in directly.

### Related issues

None found. The proposed shape (PR follows): a persisted `manuallyLocked` flag on the account's password policy, journaled through the existing `AlterUserOpType.LOCK_ACCOUNT`, enforced at password authentication only with MySQL's `ER_ACCOUNT_HAS_BEEN_LOCKED` (3118), `ACCOUNT_UNLOCK` also resetting the failed-login state (as MySQL does), `CREATE USER ... ACCOUNT_LOCK` honored, and `SHOW CREATE USER` printing `ACCOUNT_LOCK`. Existing sessions are not terminated (MySQL semantics). A second, separate observation for a later discussion: whether the failed-login lock itself should be journaled so it applies on every FE rather than per FE.

### Are you willing to submit PR?

- [x] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Start by tracing CREATE USER and ALTER USER through LogicalPlanBuilder, PasswordOptions, AlterUserInfo, and AlterUserOpType.LOCK_ACCOUNT; then inspect FailedLoginPolicy and the existing edit-log path. Done means ACCOUNT_LOCK is durable and enforced during password authentication, ACCOUNT_UNLOCK resets failed-login state, CREATE USER honors the option, and SHOW CREATE USER prints ACCOUNT_LOCK.

Written by the indexing model from the issue text.