Test brittleness: exhaustive ServeArgs literal blocks new config fields

A test brittleness worth fixing so config-surface work doesn't get blocked. The server's admission acceptance suite constructs the CLI `ServeArgs` as an **exhaustive struct literal** (naming all its fields positionally/by-name with no rest pattern). Any new `ServeArgs` field — e.g. a future admission or rate-limit CLI/env flag — breaks that test's compile, even though the test doesn't care about the new field.

This already had a concrete effect: it precluded adding `--admission-policy` / env override flags for admission, which is why admission is configured via its config table only. That outcome is fine on its own, but the *reason* was an accidental test coupling, not a design choice.

Fix: construct `ServeArgs` in tests with non-exhaustive form (`..Default::default()` or a small constructor/builder) so new config-surface fields can be added without a test-compile break. Low effort; removes a latent block on every future config field.

Search the server's admission acceptance suite for exhaustive ServeArgs literals and inspect how those test arguments are constructed. Replace the exhaustive construction with the requested non-exhaustive form or a small constructor, then run the admission acceptance tests and confirm that adding a ServeArgs field would no longer cause this test to fail compilation.

Written by the indexing model from the issue text.