Part of #2874

[erikdarlingdata]

Part of #2874. The one inline review nit on #2959, which merged before the fix landed.

TheConfigVersionWatermark_AdvancesOnlyInsideTheReloadSuccessBranch's doc comment still described the pre-#2959 call shape — "must sit INSIDE the braces of the if (await ReloadFromStoreAsync(...)) that guards it" — while the call site is now var appliedVersion = await ReloadFromStoreAsync(...); if (appliedVersion.HasValue) { … }. The regex the test actually runs was already correct; only the prose above it was stale, which is the kind of comment that misleads the next reader trying to work out what the test pins.

Updated to the current shape, and the second paragraph records why the negative against the outer read exists: the version #2946 shipped stamped configVersion.Value, this test froze that imprecision, and review is what caught it. Stating that in the pin is what stops the negative from looking like belt-and-braces and being dropped.

Comment-only change to a test file. 120 tests, 0 failed. No CHANGELOG.md entry, per the standing rule that lanes do not write that file.

[claude]

Reviewed. This is a comment-only fix to ControlPlaneReloadDurabilityTests.cs: no production code, T-SQL, or Lite files touched, so no parity concerns. Verified the updated doc comment against the current DarlingWorker.cs call shape (var appliedVersion = await ReloadFromStoreAsync(...); if (appliedVersion.HasValue) { _lastConfigVersion = appliedVersion.Value; } at line ~1568) — it matches. No correctness, security, or performance concerns. LGTM.