Add Documentation/MacTestEnv/ — macOS contributor dev/test environment

[mtinti]

Proposed Change

A self-contained Docker-based dev/test environment for macOS contributors. Purely additive; no upstream files touched.

Documentation/MacTestEnv/
├── README.md            Walkthrough + 'Building a Windows binary from Mac' section
├── docker-compose.yml   SQL Server 2022 Developer, linux/amd64 under Rosetta on Apple Silicon
├── setup.sh             One-shot: start container, build rdmp CLI, create TEST_* DBs, install TestDatabases.txt
├── teardown.sh          Stop container; --purge wipes the data volume
├── run-tests.sh         Wrapper around `dotnet test` with the warnings-as-errors workaround
└── TestDatabases.txt    Mac-flavoured: localhost,1433 + sa (replaces (localdb)\MSSQLLocalDB)

Verified end-to-end on darwin/arm64, .NET SDK 10.0.107, Docker 28.x — Rdmp.Core.Tests --filter "FullyQualifiedName~CohortCreation" returns 102/102 passed in ~3 minutes under amd64 emulation.

The README also documents the cross-compile recipe for both the GUI and the CLI, including first-run notes for Windows (SmartScreen, Unblock).

Companion fix

This folder pairs with PR #2330 (KeywordHelp parser line endings). Without that fix, a binary cross-compiled on macOS via the recipe documented in this folder crashes on first launch on Windows. The two changes are independently mergeable but produce a complete contributor workflow when both land.

Reviewer notes

• No behavioural change for end users. Purely additive contributor tooling.
• One latent papercut left untouched: Rdmp.Core/Rdmp.Core.csproj line 20 overrides the inherited <NoWarn> instead of appending to it, which surfaces NU1902;NU1903;NU1904 as build errors when any vulnerable transitive package is resolved. The scripts side-step it on the command line (-p:WarningsNotAsErrors='"NU1902;NU1903;NU1904"'). Happy to ship a one-line .csproj fix as a follow-up if preferred.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that would cause existing functionality to not work as expected)
• Documentation-Only Update
• Other (if none of the other choices apply) — contributor tooling

Checklist

By opening this PR, I confirm that I have:

• Ensured that the PR branch is in sync with the target branch (i.e. it is automatically merge-able) — branched off latest origin/develop (a53edfd24).
• Created or updated any tests if relevant — N/A, no production code change.
• Have validated this change against the Test Plan — migration / performance / release-testing sections don't apply. The "new functionality" questions are addressed above (no GUI/CLI functionality changes, only contributor documentation).
• Requested a review by one of the repository maintainers
• Have written new documentation or updated existing documentation to detail any new or updated functionality and how to use it — Documentation/MacTestEnv/README.md, ~290 lines: walkthrough, daily commands, Windows cross-compile recipe, credentials, known issues, troubleshooting.
• Have added an entry into the changelog