Task: Close the test-db rerun-safety gap

Observed during the CDash Experimental reruns that closed task 2DFEF8F6:

• An aborted ores.iam.core.tests run left 8 OPEN rows per table in the shared per-worktree test database: faker-named tenant_types and tenant_statuses rows (CD 1..8) in the system tenant ffffffff-ffff-ffff-ffff-ffffffffffff, change_reason_code system.test, commentary "Synthetic test data", performed by ores_brave_hopper_test_dml_user. Both the parallel attempt and serial rerun #1 aborted on duplicate keys against these rows; the failing suite teardown then closed all 16 rows in one multi-row close (8 timestamps within 0.2 ms) and serial rerun #2 was green on the clean database.
• Open rows collide with fresh inserts because the partial unique indexes (e.g. tenant_types_name_uniq_idx ... WHERE valid_to = infinity) constrain only OPEN rows. Raw DELETE on an OPEN row is translated by the ON DELETE DO INSTEAD rules into UPDATE ... SET valid_to = clock_timestamp(); DELETE RETURNING errors without a RETURNING rule.
• Evidence to verify against: fixture writing in ores.testing/database_helper.cpp and test_database_manager.cpp, the iam repository fixture tests, CTest.cmake (PARALLEL_LEVEL = nproc capped by CTEST_MAX_PARALLELISM), and the bitemporal close rules in the ores_iam DDL.
• Same residue class was already documented for rat runs on 2026-08-12 in the iam-rat-residue memory (identical CD N faker rows, partial unique index collisions, soft-close remediation); that memory's manual remediation is what this task automates away. Note the test DML user is environment-specific (ores_swift_curie on swift_curie, ores_brave_hopper on brave_hopper).
• The earlier claim in this note that "the failing suite teardown then closed all 16 rows" is wrong: no teardown exists in the fixture suites or the harness that could close system-tenant rows. The close observed at 20:21:14 on 2026-09-04 was a manual remediation during the incident forensics.

The mechanism, verified end to end against the live database:

• The iam repository tests (repository_tenant_type_repository_tests.cpp, repository_tenant_status_repository_tests.cpp) write tenant types and statuses into the system tenant (ffffffff-ffff-ffff-ffff-ffffffffffff) with markers change_reason_code = 'system.test', the test DML user as session user, and version = 1.
• The row name is deterministic across every process and run: faker::word::noun() returns the fixed word CD (probe confirmed identical CD 1..N names across three independent processes), while the type=/=status field is random per process (std::random_device-seeded).
• A run that aborts mid-run (kill, crash, timeout) skips all cleanup, leaving its rows OPEN (valid_to = infinity). The harness terminates only the per-process test tenant at testRunEnded; nothing touches system-tenant rows. Even a fully successful run leaves its CD rows OPEN, so the very next run of the binary fails.
• The rerun regenerates the same names but fresh random types. The BEFORE INSERT trigger closes a prior OPEN row keyed on (tenant_id, type) only, so it never matches the residue; the insert then collides on the partial unique indexes tenant_types_name_uniq_idx / tenant_statuses_name_uniq_idx (WHERE valid_to = infinity). Reproduction output:

ERROR: duplicate key value violates unique constraint
"tenant_types_name_uniq_idx"
DETAIL: Key (tenant_id, name)=(ffffffff-ffff-ffff-ffff-ffffffffffff,
CD 1) already exists.

• The ores_iam_tenants_tbl writer in the same binary does not poison reruns: its code, hostname and id are random per run, and the table has no partial unique index on the deterministic "Test Tenant N" name. Seed rows are safe from the sweep: they carry change_reason_code = 'system.initial_load' and are performed by the DDL user, not the test DML user.

Pre-run sweep at the harness level: database_lifecycle_listener now closes orphaned synthetic OPEN rows at testRunStarting in every table a binary registers via register_pre_run_sweep_table; ores.iam.core.tests registers ores_iam_tenant_types_tbl and ores_iam_tenant_statuses_tbl. The sweep issues a plain DELETE scoped to tenant_id = system, change_reason_code = 'system.test', performed_by = current_user and OPEN rows; each table's ON DELETE DO INSTEAD rule rewrites it into UPDATE ... SET valid_to = clock_timestamp() on the current row, so the close honours the bitemporal semantics, is idempotent, and preserves the closed rows as history. A failing table is logged and skipped so an unhealthy database cannot abort the run.

Reproduction result (acceptance 3): a [repository] run was killed mid-run with SIGKILL at 19 s, leaving 4 OPEN CD rows in each table; the rerun with no manual intervention passed all 53 test cases.