Write an integration test that keeps a list endpoint within a small database-command budget.

• Use the real relational provider in an isolated database.
• Reset setup-command counts before the request.
• Choose a small budget that allows intentional split-query behavior.
• Keep the interceptor out of production registration.

I measure commands at the boundary where the regression hurts. A budget assertion is more durable than exact SQL text and still catches per-row queries. I seed enough parent rows to make growth visible.

[Fact]
public async Task Orders_list_has_bounded_database_command_count()
{
    var counter = new CommandCountingInterceptor();
    await using var factory = await ApiTestFactory.WithIsolatedDatabaseAsync(
        configureDb: options => options.AddInterceptors(counter));

    await factory.SeedOrdersWithLinesAsync(orderCount: 25);
    counter.Reset();

    var client = factory.CreateAuthenticatedClient("user-1", "orders.read");
    var response = await client.GetAsync("/api/orders?pageSize=25");
    response.EnsureSuccessStatusCode();

    Assert.InRange(counter.ExecutedCommandCount, 1, 2);
}

This is a targeted relational integration test, not a universal command-count rule. The budget belongs to one important endpoint and should change deliberately when query architecture changes.

• The endpoint intentionally uses a split query.
• Setup commands pollute the count.
• Lazy loading triggers during serialization.
• Retries duplicate a command after a transient test fault.

• Run with several page sizes and confirm command count stays bounded.
• Assert the response data remains correct.
• Keep provider retries disabled unless the test targets retries.

• Using EF InMemory where no SQL commands exist.
• Asserting an exact SQL string.
• Counting setup and migration commands.
• Applying one arbitrary budget to every endpoint.