v4-migrator 5.0.4 bootstrap baselines init migration instead of executing it on empty PostgreSQL database

### Current Behavior

When migrating from Dependency-Track 4.14.2 to 5.0.4, the bootstrap command fails on a completely empty PostgreSQL target database.

The migration stops with:

ERROR: relation "VULNERABLESOFTWARE" does not exist

Full error:

org.flywaydb.core.internal.exception.FlywayMigrateException:
Failed to execute script
V202605051142__vulnerablesoftware_full_purl_idx.sql

SQL State : 42P01
Message : ERROR: relation "VULNERABLESOFTWARE" does not exist

Source version:
Dependency-Track 4.14.2

Target version:
Dependency-Track 5.0.4

Migrator:
ghcr.io/dependencytrack/v4-migrator:5.0.4

Target database:
PostgreSQL 16.14

Target PostgreSQL database is hosted on IBM Cloud Databases for PostgreSQL.

Bootstrap reports:

Successfully baselined schema with version: 202605022031

Then executes:

V202605022032__drop_liquibase_tables.sql

And afterwards fails on:

V202605051142__vulnerablesoftware_full_purl_idx.sql

with:

ERROR: relation "VULNERABLESOFTWARE" does not exist

Database state after failure:

SELECT COUNT(*)
FROM information_schema.tables
WHERE table_schema='public';

Result:

1

Table list:

public.flyway_schema_history

Flyway history:

202605022031 Flyway Baseline
202605022032 drop liquibase tables

No Dependency-Track tables are created.

Investigation:

The migration image contains:

org/dependencytrack/migration/V202605022031__init.sql

This file contains:

CREATE TABLE "VULNERABLESOFTWARE"

and all other core Dependency-Track table definitions.

The migration that fails contains:

CREATE INDEX IF NOT EXISTS "VULNERABLESOFTWARE_FULL_PURL_IDX"
ON "VULNERABLESOFTWARE"
("PURL_TYPE", "PURL_NAMESPACE", "PURL_NAME", "VERSION")
WHERE "PURL_TYPE" IS NOT NULL;

It appears that bootstrap treats V202605022031__init.sql as already applied (baseline) instead of executing it on an empty database.

As a result, later migrations reference tables that were never created.

I also verified that the database user has CREATE privileges on the public schema.

Query:

SELECT has_schema_privilege(current_user, 'public', 'CREATE');

Result:

true

The migrator is also able to create flyway_schema_history successfully, suggesting this is not a connectivity or permissions issue.

### Steps to Reproduce

1. Create a new empty PostgreSQL database.

2. Run:

docker run --rm -it \
ghcr.io/dependencytrack/v4-migrator:5.0.4 \
bootstrap \
--target-url "jdbc:postgresql://:/?sslmode=allow" \
--target-user \
--target-pass

3. Enter the target database password.

4. Observe that bootstrap reports:

Successfully baselined schema with version: 202605022031

5. Observe that bootstrap subsequently fails during Flyway migration:

V202605051142__vulnerablesoftware_full_purl_idx.sql

ERROR: relation "VULNERABLESOFTWARE" does not exist

6. Connect to the target database and verify that only the flyway_schema_history table exists in the public schema.

### Expected Behavior

On a new and empty PostgreSQL target database, bootstrap should execute V202605022031__init.sql and create the complete v5 schema before executing subsequent migrations.

The VULNERABLESOFTWARE table should exist before V202605051142__vulnerablesoftware_full_purl_idx.sql is executed.

After bootstrap, the target database should contain all core Dependency-Track tables defined in V202605022031__init.sql.

### Dependency-Track Version

5.x

### Browser

N/A

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this defect was already reported

Start with org/dependencytrack/migration/V202605022031__init.sql and the bootstrap path that baselines it; compare that behavior with V202605022032__drop_liquibase_tables.sql and V202605051142__vulnerablesoftware_full_purl_idx.sql. Reproduce against an empty PostgreSQL database using the documented docker run command, then verify bootstrap executes the init migration and creates VULNERABLESOFTWARE plus the remaining core tables before later migrations.

Written by the indexing model from the issue text.