Installer MariaDB/MySQL migration fix

Problem:
During browser installation Doctrine could fail with an error such as:

    SAVEPOINT DOCTRINE_13 does not exist

Cause:
The application's existing migrations contain MySQL/MariaDB DDL statements
(CREATE TABLE, ALTER TABLE, CREATE INDEX, etc.). MySQL-compatible servers can
implicitly commit transactions while executing DDL. Doctrine then tries to
release/commit a transaction or savepoint which MariaDB has already ended.

The project already configured Doctrine Migrations with:

    transactional: false

That setting ensures newly generated migrations are created as
non-transactional, but it does not retroactively alter migration classes that
were generated earlier. Existing migration classes inherited
AbstractMigration::isTransactional(), whose default is true.

Fix:
Every existing Webberdoo Starter migration now explicitly contains:

    public function isTransactional(): bool
    {
        return false;
    }

This prevents Doctrine from starting transaction/savepoint wrappers around the
DDL-heavy existing migrations and avoids the MariaDB SAVEPOINT failure.

The browser installer itself already invokes Doctrine migrations before creating
the installation owner and does not wrap the whole final installation step in a
separate Doctrine transaction, so no installer-controller architecture change is
required.

No .env or .env.local files are included or modified.

Retry guidance:
If this was a failed fresh installation, some DDL may already have been committed
by MariaDB. Doctrine normally continues from its migration metadata. If the
failed attempt left an inconsistent partial schema and the database contains no
important data, the safest retry is with a clean empty database.