Defer the deadline scanner's adopter roster to the pin that asserts it

[erikdarlingdata]

CommandDeadlineScanner's class summary opened with a count of the pins routing through it and a roster of their names. Nothing checked either one. The count was written five in #2938, six in #2940, seven in #2966 and nine in #2972; the roster never moved at all, which is the worse half — a reader looking for the adopters found the names as of extraction and no hint that others had joined.

CommandDeadlineScannerAdoptionTests already re-derives the adopting set from the tree and declares the deliberate abstainers beside it, so any *CommandTimeoutTests.cs landing in neither list fails the build. The summary now points there and states nothing countable itself, so there is no figure left to go stale a fourth time.

Two other figures go with it.

The Assigns doc argued that the name qualification is load-bearing rather than defensive by quoting "112 of the MCP surface's 119 sites" in the present tense. That numerator no longer holds: every command site in McpReadCommandTimeoutTests' scope — Mcp/ recursively plus CustomViewStore.cs and DarlingWebEndpoints.cs, 126 of them today — is assignment-spelled. The claim keeps its point and hands the census back to the pin that maintains it.

The adoption pin's own rationale counted the names in the roster it replaced. That figure described a list this change removes, so it goes too.

Deliberately unchanged: IlCallSiteScannerTests' "two of the five pins" counts #2898's IL-walk duplicators, and CSharpSourceWalker's "five copies" counts what #2913 consolidated. Different censuses from this one.

Verification

Darling.Tests compiles on macOS with -p:EnableWindowsTargeting=true: 0 errors, 38 pre-existing analyzer warnings, 4.3 s.

The real CommandDeadlineScanner.cs, CommandDeadlineScannerAdoptionTests.cs, DocCommentHygieneTests.cs, CSharpSourceWalkerTests.cs and CSharpSourceWalker.cs were compiled by absolute path into a throwaway net10.0 xunit.v3 host staged outside the repo tree: 50 tests, Failed: 0, Not Run: 0. Test counts moved 24 → 25 → 50 across builds with a distinct output-assembly hash each time, so no run reported a previous binary's results.

Red-first, one mutation at a time. A planted second <summary> opening in CommandDeadlineScanner.cs (anchor count 1, content hash a20e3a2d → 5bddb6f2) failed both DocCommentHygieneTests rules by name — which is simultaneously the proof that the hygiene scan reaches this file, since it enumerated 2191 .cs files including it. Dropping ViewerCommandTimeoutTests.cs from s_adopters (anchor count 1, e7ebfbf7 → 095ad86d) failed the adoption pin, so the authority this comment now defers to is enforced rather than decorative. Both mutations restored byte-exact, with the tree clean afterwards.

No project sets GenerateDocumentationFile, so CS1574 cannot fire on a wrong cref. Both crefs this change adds — CommandDeadlineScannerAdoptionTests and McpReadCommandTimeoutTests — were verified by grep and are each already crefed elsewhere in the same project.

[claude]

Reviewed. This PR only touches XML doc comments in Darling/Darling.Tests/CommandDeadlineScanner.cs and CommandDeadlineScannerAdoptionTests.cs — no T-SQL, no Lite/Darling app-code changes, no security or performance surface.

Spot-checked the factual claims against the current tree:

• The 9 adopters / 1 abstainer listed in CommandDeadlineScannerAdoptionTests.s_adopters/s_abstainers match the 10 *CommandTimeoutTests.cs files that actually exist.
• The new "126 sites" / "McpReadCommandTimeoutTests" cross-reference matches that file's own asserted count and scope (Mcp/ + CustomViewStore.cs + DarlingWebEndpoints.cs).
• No .csproj in the repo sets GenerateDocumentationFile, consistent with the PR body's claim that a bad <see cref> won't fail the build via CS1574 — both crefs added (CommandDeadlineScannerAdoptionTests, McpReadCommandTimeoutTests) resolve to real classes anyway.

Nothing to flag — no correctness, parity, security, or perf issues found.