feat(testing): docker-based local nuget server for tier 3 channel

[ChrisonSimtian]

Summary

Minimum-viable Tier 3 release channel: a Docker-based local NuGet server for pre-merge testing of Fallout.* changes. Lets a maintainer (and, later, CI) verify a change works in a real consumer project before merge, without polluting the GitHub Packages (Tier 2) feed with abandoned PR builds.

Refs #279.

Tool choice: BaGet (with caveat)

BaGet — open-source .NET NuGet server, official Docker image. The issue nominated it and I confirmed it's still the right shape for "docker compose up and push a package":

• Pro: purpose-built NuGet server, runs as a single container, matches the brief exactly.
• Con: repo is effectively stale — last commit January 2023, not archived but quiet. Docker image and NuGet v3 protocol surface remain functional.

Sleet was the considered alternative: actively maintained (last commit March 2026), but it's a static-file feed generator — it doesn't host an HTTP endpoint itself, so you'd need a separate web server (nginx) to serve files, plus a different push workflow. Doesn't fit the "spin up a server with docker compose" shape the issue describes.

Sticking with BaGet for v11. The client-side workflow (push to a NuGet v3 URL, restore from it) is feed-agnostic, so swapping to a maintained alternative later won't break anything documented here. A follow-up to track that swap may be worth filing — flagging for Chris's call.

What's in this PR

• tests/integration/docker-compose.yml — BaGet on 127.0.0.1:5555, FileSystem storage, SQLite metadata DB, API key auth (env-overridable, defaults to FALLOUT_LOCAL_DEV), named volume fallout-local-nuget-data for persistence.
• tests/integration/README.md — start/stop/push/consume instructions, deferred-items list linking Docker-based local NuGet server for pre-merge testing (Tier 3 channel) #279.

Compose-file location

Chose tests/integration/ (the brief's preferred option) since this is a testing aid that fits alongside the existing tests tree, and the directory doesn't yet exist so there's no namespacing conflict.

Notable decisions

• Port 5555 (brief's suggested default) bound to 127.0.0.1 only — this is dev/CI, never externally exposed.
• Static dev-only API key FALLOUT_LOCAL_DEV documented in README; overridable via FALLOUT_LOCAL_NUGET_API_KEY env var before compose-up.
• Named volume (fallout-local-nuget-data) so packages survive docker compose down and only get wiped on explicit down -v.
• No optional push script — README's two code snippets (single push + loop over *.nupkg) cover it without adding a maintenance surface. A dotnet fallout target is the better long-term home for that automation per the issue's acceptance criteria; deferred.

Out of scope (per issue #279)

• Wiring tests/Consumers/Fallout.Consumer.Local/ to restore from the local feed.
• CI integration / GitHub Actions workflow.
• Devcontainer / Codespaces setup.
• PR-scoped versioning automation (Fallout.X.M.P-pr.NNN.YYYYMMDD.SHA).
• A dotnet fallout target that packs-and-pushes all Fallout.* artifacts.

All flagged as follow-ups in the README; #279 stays open to track them.

Test plan

• docker compose -f tests/integration/docker-compose.yml up -d starts BaGet without error.
• curl http://localhost:5555/v3/index.json returns the NuGet v3 service index.
• dotnet pack a Fallout.* project, then dotnet nuget push --source http://localhost:5555/v3/index.json --api-key FALLOUT_LOCAL_DEV succeeds.
• Pushing without --api-key (or with the wrong key) is rejected.
• A clean project can dotnet restore --source http://localhost:5555/v3/index.json the pushed package.
• docker compose down then up -d again — package still present (named volume persists).
• docker compose down -v — package wiped, server starts clean.

(I didn't run these — the worktree may not have Docker installed and the brief explicitly says config + docs is the deliverable, not a running container.)