[Feature]: Native DB creation + seeding support

[Muppity]

Use case

Developers spinning up the Azure SQL Database container locally (via docker run or docker-compose) currently get a bare database instance with no database. Teams using ORMs or migration tools expect the container to create an initial database and optionally seed it with schema/data on first boot — the same experience the official Postgres image provides via POSTGRES_DB and /docker-entrypoint-initdb.d. https://www.postgresql.org/docs/current/app-initdb.html

Current workaround

The only option today is to build and maintain a custom wrapper image on top of the official base image — for example, something that reads a DB_NAME-style env var to create a database on first startup, and mounts a host folder to /docker-entrypoint-initdb.d containing init/seed .sql scripts, with custom logic to track what's already been applied. Which is manageable but it isn't official, isn't documented, so it would be great to have an official image with this approach for the Azure SQL container.

Proposed behavior

• An env var (e.g. MSSQL_DATABASE) to auto-create a database on first boot, mirroring POSTGRES_DB
• Native support for mounting /docker-entrypoint-initdb.d, executing .sql (and ideally .sh) scripts on first startup against an empty data volume
• A defined convention for one-time vs. repeatable scripts, since this Azure SQL Database container doesn't have the same "empty data dir = first boot" simplicity Postgres has, and idempotency would need to be handled explicitly
• A container healthcheck that reflects "seeding complete," not just "engine is up"

Who benefits

All developers

Urgency

Nice to have

Additional context

As a developer, I want the Azure SQL Database container to natively create and seed a database on first run, so that I don't need to hand-roll a custom wrapper image.

As a developer setting up local/CI environments with Azure SQL Database in Docker
I want the container to support an env-var-driven database creation and a native init/seed script mechanism (like Postgres' docker-entrypoint-initdb.d)

So that I can get a ready-to-use, seeded database on first container startup without maintaining custom image tooling

Acceptance Criteria:

• Given MSSQL_DATABASE= is set and no volume-persisted data exists, when the container starts, then a database named is created automatically.
• Given a host folder is mounted to /docker-entrypoint-initdb.d, when the container starts for the first time (empty data volume), then all .sql scripts in that folder are executed against the created database, in a deterministic order.
• Given the container has already been initialized (persisted volume, previously run), when restarted, then init scripts are not re-run automatically.
• Given init scripts are applied, when checking container health, then the healthcheck reflects successful completion of seeding, not just engine availability.
• Given a script fails during initialization, when the container starts, then the failure is surfaced clearly in logs and the container does not report healthy.