Add shared-library regression coverage to close the #150 detection gap

[janstaelensskyline]

Why

The existing BOOST-DailyRegression-* repos contain no project that is referenced by a sibling project. Nothing in the downstream suite ever depended on MSBuild resolving a ProjectReference before compiling its consumer.

That is the exact gap that let #150 through: it passed the entire downstream suite, then broke real solutions with

CSC : error CS0006: Metadata file '<shared library>.dll' could not be found

and had to be fixed in #151.

What

New regression repo: SkylineCommunications/BOOST-DailyRegression-SharedLibrary, registered here against Master Workflow.yml.

Its solution deliberately combines the two shapes that were observed to fail:

                      SharedLibrary            <-- consumed by everything
                       /            \
             MidLevelLibrary      Consumer1..6  <-- wide flat fan-out
              /     |     \
     BranchA   BranchB   BranchC                <-- multi-level chain
              \     |     /
                TopLevelApp

• Flat fan-out reproduces the wide case, where many siblings race one shared library.
• Four-level chain reproduces the deep case. This matters: a flat fan-out alone is a flaky race that frequently passes, while the transitive chain fails deterministically. Without it the regression repo would itself be unreliable.

Every project genuinely consumes types from what it references, so the references can't be optimised away.

Verification

End-to-end, on the real runner:

Pinned to	Run	Result
pre-fix commit (0ff78eb)	31783930026	❌ failure — Build remaining projects, CS0006 on SharedLibrary.dll and MidLevelLibrary.dll
current main (fixed)	31783890542	✅ success

So the repo demonstrably detects this class of regression rather than just existing. It also reproduces locally with a plain dotnet build ... -p:BuildProjectReferences=false (exit 1) vs. without (exit 0) — documented in its README.

The temporary verification branch has been deleted.

Notes

• DOWNSTREAM_MAP JSON validated (7 entries parse).
• The repo follows the sibling layout: ci-cd.yml (@main), pr-ci-cd.yml (@test-downstream), regression.yml (daily), pr-regression.yml (repository_dispatch receiver).
• SONAR_NAME / SONAR_TOKEN / TEAMS_WEBHOOK are not yet set on the new repo, so SonarCloud and the Teams notification are inert until someone configures them. The build coverage this PR is about works regardless.

[janstaelensskyline]

Receiver wiring verified

Fired the real repository_dispatch (test-reusable-workflow) at the new repo to prove the /test path works end to end:

Run	Result
31784281854 — pr-regression.yml receiver	✅ success (4m0s)
31784289793 — pr-ci-cd.yml on branch	✅ success
31784432691 — pr-ci-cd.yml on tag 2026.08.14.10	✅ success

The orchestrator's branch run, release tagging and tag run all completed, so the repo behaves exactly like its siblings.

Also pushed a small doc correction: the Test Downstream.yml header told you to create .github/workflows/test-downstream.yml, but every registered downstream repo actually uses pr-regression.yml calling the shared BOOST-DailyRegression orchestrator. The header now documents what is really wired up.

Secrets still to set (org admin)

Not blocking the coverage this PR adds — the build runs green without them — but for parity with the sibling repos someone with admin rights should add to BOOST-DailyRegression-SharedLibrary:

• TEAMS_WEBHOOK — daily regression / pr-regression Teams notification (siblings have it at repo level; the run still succeeded without it)
• SONAR_TOKEN secret + SONAR_NAME variable — SonarCloud analysis