Give the test run its own database

A test run should create or use a database of its own, and empty it with the run, so it neither sees nor leaves environment state. Today ORES_TEST_DB_DATABASE carries the same name as ORES_DB_DATABASE, so both point at ores_dev_swift_curie.

The suites are well behaved about tenants: each makes its own, named for the test, and none of them truncates a table or touches another party's rows. The problem is the database underneath them. A ctest run leaves its tenants and fixtures in the developer's environment database. After one gate run the tenant table held 52 live rows, and the reporting instances were the suites' own CD_instance-N rows.

That costs a reader twice. A query written for one tenant returns many, and nobody can tell which rows are theirs. And two runs on one machine share rows, so a suite that counts or lists sees the other run's work.

It does not explain a missing provision. A provisioned ACME tenant disappears because the gate recreates the database before the suites run, which is a separate capture: The check gate recreates the developer database.

• .env: ORES_TEST_DB_DATABASE and ORES_DB_DATABASE hold the same name.
• The gate's ctest check runs ./compass.sh test run --preset {preset}, which inherits that environment.
• The evidence: 52 live tenants and CD_instance-N rows in ores_reporting_report_instances_tbl after a gate run on 2026-10-25.