Part of #2936

[erikdarlingdata]

Part of #2936. Comment-only. Two claims the widening in #2955 made false, which its own review caught after that PR had already merged, so they land here instead.

DarlingWorker.cs — the store-migrate block still said "This block is the ONLY step of the collection loop's start that kills collection." #2955 is precisely what makes that untrue: the config load and the managed-Postgres bootstrap are triaged the same way through the same predicate and reach the same LogCritical + return when the classifier declines or the budget runs out. A reader counting kill points from that sentence would find one instead of three.

StartupFailureTriage.cs — Attempts and IsRetryable still described themselves in terms of "the collection loop's first store interaction" although all three sites now share them. Attempts now also states the part that is easy to get wrong: each site keeps its own stopwatch, so the count is per site and not a budget the three draw down together.

No behaviour change; git diff is comment text only. Verified: the full solution builds with 0 errors, and the 62 tests compiled from the real StartupFailureTriageTests.cs + FleetIdentifierScrubTests.cs stay green.

[claude]

Reviewed. This is a comment-only PR (no code/logic changes), and I traced both claims against the current source:

• DarlingWorker.cs: confirmed there are exactly three StartupFailureTriage-gated sites in the collection loop's startup — config load (~L730), managed Postgres bootstrap (~L845), and store migrate (~L1112) — each with its own retry-budget Stopwatch and each ending in LogCritical + return on the terminal path. The updated wording ("LAST of the three startup steps that can kill collection") is accurate; the store-migrate block is indeed the third/last of the three.
• StartupFailureTriage.cs: Attempts and IsRetryable are shared by all three call sites, and each site does keep its own independent stopwatch (configRetryBudget, bootstrapRetryBudget, storeRetryBudget), so "per site, not a shared budget" is correct. The "single typed carve-out" reference in IsRetryable's new summary matches the class remarks and the file-system-verdict special case in the method body.

No T-SQL touched, so the CONTRIBUTING.md T-SQL style rules don't apply here. No Lite counterpart exists for StartupFailureTriage/DarlingWorker (this is Darling-specific managed-Postgres/service-startup machinery that Lite's architecture doesn't have), so there's no parity drift to flag. No security, correctness, or performance concerns — this is a doc-accuracy fix that correctly follows up on the #2955 widening.

No changes requested.