Upgrade-path tests read the preload line where the managed settings now live (#4336)

[erikdarlingdata]

Refs #4336, #4405 and #4358.

Why

The 2026-09-26 nightly (3.8.0-nightly.20260926.473) failed three gated upgrade-path tests on the same shape:

• DarlingStoreUpgradeTests.RuntimeAdvance_SameMajorStoreWithRealData_SwapsWithoutPgUpgradeAndKeepsEverything_Gated (both stamped cases) asserted shared_preload_libraries = 'timescaledb' against postgresql.conf alone.
• ManagedConfUpgradePathTests.UpgradeInPlace_OperatorLineBelowInclude_CarriedAndApplied_NoManagedKeyDuplicated_Gated counted that same literal only in postgresql.conf, expecting exactly one; its pg_file_settings "applied" check never ran because the count assert above it failed first.

After #4336's Step A, a migrated store's shared_preload_libraries line moves into darling-managed.conf, reached from postgresql.conf through an include 'darling-managed.conf' line. The three tests still looked for the literal string only in postgresql.conf, so they failed against the actual field shape — the bundled managed store on the production Windows boxes builds and migrates exactly this way.

What changes

Adds one shared, internal test helper, ManagedPreloadAssert, used by all three tests:

• File-level check (FileLevel_HasOneManagedPreloadLine_WithBothLibraries): reads both postgresql.conf and darling-managed.conf from the data directory and parses every effective (non-comment) shared_preload_libraries assignment in each. Asserts exactly one such assignment across the two files (the "no managed key duplicated" rule), that it lives in the managed file, that postgresql.conf carries the include line reaching it, and that its value holds both timescaledb and pg_stat_statements (the v13 merge always keeps both, so this suite's managed stores always carry both).
• Live check (Live_ReportsBothLibraries_SourcedFromManagedConf): opens a Pooling=false connection and reads pg_settings.setting / pg_settings.sourcefile for shared_preload_libraries, asserting both libraries are reported and the source file ends with darling-managed.conf — the live counterpart of the field canary.

The two RuntimeAdvance_SameMajor... cases now call both checks. The operator-line test calls the file-level check in place of its old single-file count, and keeps its pg_file_settings "applied" check afterward, unchanged.

Also adds one render-level unit fact, ManagedConfFileTests.RenderBody_PreloadLine_IsExactlyOne_WithBothLibraries, that pins the same rule directly on ManagedConfFile.RenderBody's output — ungated, runs on every build. Verified with a temporary mutation: appending a second shared_preload_libraries line to the render's output turned this fact (and the existing RenderBody_PreloadMerge_KeepsAnOperatorLibraryInForce) RED, then reverting the mutation restored GREEN.

Test plan

• Darling.Tests and Lite.Tests both build 0 errors / 0 warnings-that-matter with -p:EnableWindowsTargeting=true.
• Ran ManagedConfFileTests in-process on macOS: 33/33 pass, including the new render-level fact.
• Ran DocCommentHygieneTests in-process: 77/77 pass.
• Ran ManagedConfUpgradePathTests in-process: 5 total, 1 skipped (gated, no PG runtime env vars on this rig), 0 failed.
• Ran DarlingStoreUpgradeTests in-process: 146 total, 13 skipped (gated), 6 failed — all six are pre-existing macOS-path failures unrelated to this change (e.g. a C:\pg\lib\... literal-path parsing case), confirmed unchanged against the pre-fix dev tip with the same class.
• The three gated tests this PR touches cannot run here (DARLING_TEST_PGRUNTIME_* real-runtime env vars, Windows-only bundled PostgreSQL). That nightly's failing run is the RED; the next nightly dispatch is the GREEN this PR expects.

CHANGELOG entry

SECTION: None
ENTRY: None: test-only change, no user-visible effect.