`expect_that!` needs a `#[gtest]` test context to collect failures; the
`#[sqlx::test]` macro doesn't provide one, so using it here panics with
"No test context found" instead of running the assertion. Switch to
`assert_that!`, which works without the gtest context and matches the
convention used by every other test in this file.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Spawns the actual gateway binary with `TENSORZERO_POSTGRES_URL` set
against a migrated Postgres and nothing else (no `--config-file`, no
`--default-config`, no `ENABLE_CONFIG_IN_DATABASE` feature flag) and
verifies the gateway binds a port, serves a healthy `/health`, and
returns a well-formed `StatusResponse` from `/status`. This is the
end-to-end counterpart to the unit-level empty-DB test on
`load_config_from_db`: that one proves the loader returns defaults,
this one proves the full binary actually reaches listening state and
answers HTTP with that defaulted config.

Also factors the "wait for listening + parse bound addr + build
ChildData" tail of `start_gateway_impl` into a shared
`await_gateway_listening` helper so the new
`start_gateway_from_db_url_on_random_port` helper doesn't duplicate it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Extend the new integration test from "does the gateway serve /health"
to the full config-in-database scenario the UI will build on top of:
migrated Postgres, no config rows, no `--config-file`, feature flag
on, then assert:

- `/health` 200
- `/status` returns `ok` + a non-empty `config_hash`
- `/internal/config_toml` returns a default editable TOML whose hash
  matches `/status`, and whose `path_contents` is empty (no
  user-provided templates)
- The TOML body parses as a valid TOML table

The helper `start_gateway_from_db_url_on_random_port` now takes an
`extra_env` slice so callers can either exercise the implicit-opt-in
path (env var only) or the full config-in-database scenario (feature
flag on) without duplicating the subprocess plumbing. Adds `toml` to
gateway dev-dependencies for assertion-side parsing.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds a dedicated e2e scenario, parallel to `live-tests`,
`live-tests-config-in-database`, `evaluation-tests`, and the existing
live flavors: gateway booting from a migrated-but-empty
Postgres + ClickHouse stack with `ENABLE_CONFIG_IN_DATABASE=true` and
no `--config-file`. This is the deploy shape the configure-via-UI
story builds on — schema present, no config rows, no files on disk.

New pieces, all mirroring the existing config-in-database pattern:

- `crates/tensorzero-core/tests/e2e/docker-compose.db-only-boot.yml`:
  override of `docker-compose.live.yml` that drops
  `gateway-migrate-config`, flips the feature flag, clears
  `--config-file`, and uses `!override` on `volumes` to remove every
  inherited bind mount (config TOMLs, fixtures, credentials) — so the
  gateway literally has nothing on disk to read.
- `crates/tensorzero-core/tests/e2e/db_only_boot/mod.rs`: two
  `#[gtest] #[tokio::test]` Rust tests that run inside the live-tests
  container and hit the gateway over the compose network: one asserts
  `/status` reports the default config and a non-empty hash, the other
  asserts `/internal/config_toml` returns the same hash with empty
  `path_contents` and a TOML body that parses back as a valid table.
- `crates/.config/nextest.toml`: new `db-only-boot` profile filtering
  to `db_only_boot::` tests, and `e2e`'s `default-filter` excludes
  them so they only run in their own CI job.
- `.github/workflows/db-only-boot-e2e.yml`: new reusable workflow
  standing up the stack, running the profile inside `live-tests`, and
  asserting the gateway logs show the DB-authoritative boot banner.
- `.github/workflows/general.yml`: wires the new job behind
  `detect-changes.outputs.code`; `ci/check-all-general-jobs-passed.sh`
  adds it to `ALLOWED_SKIP` so the merge queue tolerates skipped runs.

Also drops the subprocess-spawning `crates/gateway/tests/boot_from_empty_db.rs`
and its helper additions in `gateway/tests/common/mod.rs` and
`gateway/Cargo.toml` — superseded by the in-container Rust test.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two mistakes in the initial push of the new job:

- The workflow pulls `tensorzero/live-tests:sha-$SHA` but only declared
  `build-gateway-container` in `needs:`. Adds
  `build-live-tests-container` and `build-fixtures-container` to the
  dependency list, matching `live-tests-config-in-database`. Also
  gates the job on the same fork/dependabot condition the sibling jobs
  use.
- `pre-commit`'s `check-yaml` can't parse Compose's `!override` custom
  tag, so `validate` failed on the new compose file. Excludes that
  single file from `check-yaml`; Docker Compose still validates it at
  stack-up time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The CI job failed because `docker compose run live-tests` started its
full `depends_on` graph — including `fixtures-postgres`, which exits
1 when loading fixtures against a migrated-but-empty DB. The whole
point of this scenario is an empty DB, so fixture loading is a
semantic mismatch.

Override `live-tests.depends_on` with `!override` to keep only the
infra + gateway + migrations services and drop `fixtures` and
`fixtures-postgres`. The `up --wait gateway` and the subsequent
`run --rm live-tests` both pass locally after this change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Run the zero-config boot scenario in both observability modes:

- Postgres-config + ClickHouse-data (default TOML-config deploy shape)
- Postgres-config + Postgres-data (single-datastore deploy)

Matches the `live-tests` workflow's `database: [clickhouse, postgres]`
matrix. When `matrix.database == postgres`, sets
`TENSORZERO_INTERNAL_TEST_OBSERVABILITY_BACKEND=postgres` so the gateway
uses Postgres as the primary observability backend and exercises its
pgcron/pgvector/trigram extension checks.

The `check-all-general-jobs-passed.sh` ALLOWED_SKIP entry
(`db-only-boot-e2e`) already covers matrix-suffixed job names via the
existing `"entry ("` prefix match — no change needed there.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Before: the three `/internal/config_toml` routes were mounted only when
`ENABLE_CONFIG_IN_DATABASE` was set at router-build time. That ties the
endpoints to a process-wide flag and means a gateway booted implicitly
from a Postgres URL (no flag, no `--config-file`) would 404 the UI's
config bootstrap even though the stored-config tables are already the
source of truth.

Now: the routes are always mounted, and `get` / `apply` gate themselves
at request time on `app_state.config_in_database` — the same bit the
boot logic records when it decides which source to load from. The
`require_config_in_database(bool, &str)` helper keeps the 501 response
consistent across endpoints.

`validate` is intentionally ungated: it is stateless (parse + run the
shared load pipeline, no DB reads or writes), and the UI needs to lint
editable TOML even against a file-backed gateway. The docstring now
says so explicitly.

Also extend `db_only_boot_returns_default_config_via_config_toml_endpoint`
to assert the collection tables (functions/models/tools/metrics) are
absent or empty, and that `base_signature` is populated so callers can
use it as a CAS token on the first apply.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>