Adopt .artifacts/ as the staging directory convention

[ChrisonSimtian]

Proposal

Standardise on a dot-prefixed .artifacts/ at the repo root as the canonical staging location for build outputs that downstream steps consume — NuGet packages, zips, test results (.trx), coverage reports, published binaries.

Today consumers see a mix: output/ (current Fallout/NUKE convention), bin//obj/ (MSBuild), various ad-hoc paths in Build.cs files.

Why

• Dot-prefix is the established invisibility convention (.git/, .vs/, .idea/, .vscode/). One .artifacts/ line in .gitignore and IDE pickers stop surfacing it.
• Single well-known CI upload path: actions/upload-artifact path: .artifacts/** works everywhere, no per-repo config.
• Aligns with .NET 8+ SDK direction: the SDK's own UseArtifactsOutput / ArtifactsPath MSBuild properties point to artifacts/. We should compose with that, not collide.

Suggested layout

.artifacts/
  packages/       # .nupkg / .snupkg
  publish/<rid>/  # dotnet publish output
  tests/          # .trx, .runsettings output
  coverage/       # cobertura/opencover xml + reports
  logs/           # binlogs, captured tool output

Why v12

v12 is already the refactor wave — pairing this convention change with the plugin SDK foundation lets consumers absorb both in one migration rather than two.

Open questions

• Migration path for consumers reading OutputDirectory / ArtifactsDirectory from Build.cs — alias, deprecate, hard-break with shim?
• Compose with .NET SDK's ArtifactsPath or override it? If we set ArtifactsPath=.artifacts/dotnet/, do per-tool MSBuild outputs land sensibly?
• Does the framework create the directory eagerly, or only when something publishes into it?
• Does consumer Build.cs opt in (UseArtifactsLayout()) or is it the new default with an opt-out?