Adopt .artifacts/ as the staging directory convention

## 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// # 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?