The T-SQL convention guard reads ForcePlanBotPolicy.Names and .Evidence short and dev is red on it: both are block-bodied now, whole range, no KnownTruncatedRanges entry (#3654 follow-up to #3663)

[erikdarlingdata]

What is red on dev

#3663 (merged 80b1668) landed ForcePlanBotPolicy.Names and .Evidence as expression-bodied members whose body is a { Count: > 0 } property pattern. TsqlConventionGuardTests.TheMemberScan_ReadsEveryDeclarationWhole reads both declaration ranges short — the same walker shape the #3607 lane banked today — so dev's build and Darling PostgreSQL tests fail on that one test. The PR's own CI reported it; the merge took the head before the fix commit reached the branch (30 s apart), so this is that fix commit, cherry-picked onto dev.

The fix

Both members are block-bodied now: if (blockers is not { Count: > 0 }) return …; return …;. Identical behaviour, whole range for the walk. Deliberately NOT a KnownTruncatedRanges entry — the census stays honest, and per the guard's own message a member the walk cannot read whole is a member no census can see into. No census scans ForcePlanBotPolicy.cs outside the bot/policy tests themselves (grepped Darling.Tests + Lite.Tests for ForcePlanBotPolicy.cs / ForcePlanBlockerNames), so nothing else's count moves.

Verified

Red-first reproduced locally: with the expression-bodied shape on disk the guard fails naming exactly ForcePlanBotPolicy.cs Evidence and ForcePlanBotPolicy.cs Names; with this change it passes. Whole local harness (22 PlanForceBotTests + 30 ForcePlanBotPolicyTests + 3 PlanForceNoWritePathTests + 14 TsqlConventionGuardTests) 69/69. Analysis builds -c Release -p:EnableWindowsTargeting=true at 0 warnings.

Follow-up to #3663 / #3654 (already closed).