Darling tests: a test-only read route no longer leaks into other test classes running at the same time (#4782)

[erikdarlingdata]

Fixes #4782.

Why

Dev CI failed at d85dc2f, in the Darling PG tests (2) job. One test failed: DarlingCustomViewsTests.CatalogDescriptors_Keys_EqualTheReadDispatchKeys, with "reads with no catalog descriptor: __test_statement_timeout". That route name belongs to another test class. It is not a real read.

ReadLatencyWebRecordingTests.ADispatchEntryThatThrowsA57014PostgresException_RecordsOneWebSample_WithOutcomeTimeout registers one extra /api/read/* dispatch entry through DarlingWebEndpoints.s_testOnlyExtraDispatchEntry, and BuildReadDispatch() adds that entry whenever it is set. That was a plain static field, so it is process-wide. The class that sets it is in the live-postgres collection, so it only runs on the PostgreSQL CI jobs. About ten other test classes call BuildReadDispatch() outside that collection, so they can run at the same time, and any of them that builds its dispatch while the entry is set sees the extra route. DarlingCustomViewsTests compares the dispatch keys with the Custom Views catalog, so it fails when that happens. That is what failed on dev.

What changes

• DarlingWebEndpoints.cs: the field is now private static readonly AsyncLocal<(string Name, ReadToolHandler Handler)?>, exposed through an internal TestOnlyExtraDispatchEntry property. Only the async flow that sets the entry, and what that flow starts or awaits, sees it. BuildReadDispatch reads the property. The seam is still null in every production run, and nothing outside Darling.Tests assigns it. This is the only product-file change, and it does nothing outside a test.
• ReadLatencyWebRecordingTests.cs: the scope class and the two doc references use the property. Every assertion is unchanged. The test builds its server after setting the entry, in the same async method, so its own server still registers the route.
• DarlingWebEndpointsTests.cs: a new test, TheTestOnlyExtraDispatchEntry_IsSeenBySameFlow_AndNotByAFlowThatDoesNotInheritIt. It sets the entry under a unique route name and asserts BuildReadDispatch() contains it in the same flow. It then runs BuildReadDispatch().ContainsKey(name) in a task started under ExecutionContext.SuppressFlow() and asserts the answer is false. The entry is cleared in a finally.
• git grep -n "s_testOnlyExtraDispatchEntry" -- Darling now shows only the field and the property.

Test plan

• RED first: with the field put back to a plain static (behind the same property), the new test fails on its second assertion, "a flow that does not inherit the setter's context must not see the entry". Total: 1, Failed: 1. The plant is not in the branch.
• Darling.Tests builds with 0 Warning(s), 0 Error(s).
• The new test, DarlingWebEndpointsTests, DarlingCustomViewsTests and AsOfWindowAnchorTests, with no DARLING_TEST_PG: Total: 172, Failed: 0, Skipped: 0.
• ReadLatencyWebRecordingTests against a throwaway local PostgreSQL 18.6 with DARLING_TEST_PG set: Total: 3, Failed: 0, Skipped: 0. The 57014 dispatch-entry test ran, so the test's own server still sees the entry.
• Those four classes together with DARLING_TEST_PG set: Total: 175, Failed: 0, Skipped: 0.
• Full Darling.Tests suite, once, with no DARLING_TEST_PG: Total: 17199, Errors: 0, Failed: 0, Skipped: 1123, Not Run: 1. The skips are the live PostgreSQL classes, which need DARLING_TEST_PG. The one not-run test is an explicit-only test, which the runner does not start unless asked.
• The live PostgreSQL classes other than ReadLatencyWebRecordingTests were not run locally; CI's PostgreSQL jobs run them.

CHANGELOG

SECTION: None

Test-only. The one product-file change is a test seam that is null in every production run.