Create the lock table in the manual migration export for an empty database - #53096

Closes #53088

What

With migration-strategy=manual against an empty database, the generated script creates the schema and, since
#51730, the DATABASECHANGELOG table, but not DATABASECHANGELOGLOCK. The server creates that one itself on
startup, in CustomLockService.init(), before the migration runs.

That was a deliberate choice when the changelog DDL was first added (3d47ab3, KEYCLOAK-3698): on the database
the script was generated from the lock table always exists by then, so emitting it would duplicate. It holds as
long as the script is applied to the same database. It does not hold for the flow the manual strategy exists for:
generate the script on one database, have an administrator apply it to a really empty one, and run Keycloak there
under a user without DDL rights. That database ends up without the lock table, and the first startup fails trying
to create it (#10149, #32535).

How

outputChangeLogTableCreationScript emits CreateDatabaseChangeLogLockTableStatement under the same rule as the
changelog table:

• only when the lock table did not exist before this server started. An administrator may have created the
  bookkeeping tables up front so that a user without DDL rights can produce the script at all; the target then
  already has the table and the DDL would break the script with already exists;
• only with the master changelog. Custom JpaEntityProvider changelogs share the same lock table, so emitting it
  per changelog would duplicate.

Whether it pre-existed is recorded in recordWhetherMasterChangelogTablePreExisted, i.e. during validation,
which runs before the database lock is taken and the table gets created. The same change is applied to the
legacy LiquibaseJpaUpdaterProvider.

Testing

• ManualMigrationEmptyDatabaseDistTest (H2, empty database): the script contains the lock table DDL exactly once.
• ManualMigrationCustomProviderDistTest (database already initialized, custom changelog outdated): the script
  contains no lock table DDL, since the table existed before the server started.
• BasicDatabaseTest.assertManualDbInitialization: the lock table is created exactly once, so
  PostgreSQLDistTest, MySQLDistTest and MariaDBDistTest guard it through the test-database profile
  (PostgreSQLDistTest run locally through Testcontainers, 7/7).

Verified end to end on PostgreSQL 17 with two roles, an owner with DDL and an application user with DML only
(has_schema_privilege(app, schema, 'CREATE') = false):

Unrelated, noticed while applying the script to PostgreSQL: the 26.8.0-51851-drop-old-expiration-idx-*
changesets are exported as MARK_RAN because their indexExists precondition is evaluated against the live
(empty) database, so the script later fails on CREATE INDEX ... already exists for the re-created indexes.
I will open a separate issue for that.