problem

application/database/DbInit.sql is the bootstrap database dump used for fresh translate5 installations. It is outdated and currently has to be regenerated manually: install from the existing DbInit.sql, apply all later database migrations, dump the resulting
database, and clean the dump according to application/database/README.

This manual process is error-prone. It can leave installation-specific artifacts in DbInit.sql, miss required dump options, include volatile runtime data, or produce a dump that is not suitable as a neutral bootstrap file for new installations.

solution

Finish Translate5/MaintenanceCli/Command/DevelopmentDbinitCommand.php so that dev:dbinit automates the DbInit.sql regeneration workflow.

The command should:

• require a configured database name that does not already exist, unless an explicit destructive option is added and confirmed
• create a fresh database with the configured connection parameters
• import the current application/database/DbInit.sql
• initialize translate5 and apply all pending DB migration files through the existing DbUpdater workflow
• fail if DB initialization, PHP migrations, SQL migrations, warnings/errors, or remaining unapplied files indicate an inconsistent result
• remove volatile data before dumping, especially cache, error log, and session-related table contents as described in application/database/README
• create a full SQL dump with the same relevant semantics as the README:
  --skip-add-drop-table
  --skip-add-locks
  --skip-disable-keys
  --skip-set-charset
  --default-character-set=utf8mb4
• ensure the dump contains no database-specific USE statement or CREATE DATABASE statement
• add the translate5 SQL license header with the current year
• clean dump output where needed:
  remove DEFINER clauses from triggers/views
  remove DELIMITER statements and normalize doubled statement delimiters
  remove NO_AUTO_CREATE_USER from SQL mode statements if present
  avoid unnecessary SET character_set_client / SET NAMES statements unless required by the selected dump implementation
• keep valid mysqldump DDL charset guard comments where needed, because DDL and data charset handling differ
• write the result to application/database/DbInit.sql by default, or to --output-file when provided
• report the generated file path and the number of applied migrations / processed tables

The implementation should prefer existing project infrastructure where possible. The existing DbUpdater should remain the source of truth for database initialization and migration execution. For dumping, either use the configured mysqldump binary with the
README-equivalent options or reuse ifsnop/mysqldump-php only if its output can be made equivalent and deterministic enough for DbInit.sql.

Acceptance criteria:

• Running dev:dbinit against a non-existing configured database creates a regenerated DbInit.sql-compatible dump.
• Running dev:dbinit against an existing configured database aborts before modifying it, unless an explicit force/drop option is intentionally implemented.
• A new installation from the regenerated DbInit.sql succeeds.
• After bootstrapping from the regenerated DbInit.sql, DbUpdater finds no pending migrations.
• The generated dump does not contain installation-specific DB names, DEFINER users/hosts, runtime cache/log/session data, or unsupported SQL mode leftovers.
• application/database/README is updated to describe the automated command as the primary process and keeps only manual notes that are still useful for troubleshooting.