Policy: support only in-support .NET targets (breaking — batched to next yearly major)

## v11 decision (2026-05-24)

Formalising the policy: **Fallout packages target only .NET versions currently in Microsoft support.** v11 is the breaking release that bakes this in — anything falling out of support gets dropped, no transition shims, no multi-targeting back-compat.

Today that means **net10.0 only** (net8 is in support until Nov 2026 but we are not multi-targeting back; consumers stay on net10 SDK to compile their build project — see below).

Pairs with #14 — the .NET 10 `setup` bug is part of the same release.

### What v11 actually delivers under this policy

- Audit `Directory.Build.props` / per-project `` and ensure nothing still references EOL TFMs.
- Codify the policy in CONTRIBUTING.md or a docs page so future PRs that add older TFMs get rejected at review.
- Communicate the breaking-release expectation in the v11 release notes / announcement.

---

## Historical context (original ticket framing — demand-gathering)

Currently `Nuke.Common` (and sibling libraries) target **net10.0 only**, matching Matt's 10.0.0 release decision. Consumers must use a `_build.csproj` on net10.0 to reference the package.

This issue documents the **deferred option** to multi-target on net8.0 + net10.0 — taken intentionally for now, with this issue as the place to surface real demand if it materializes.

### Why we chose single-target

| Factor | Rationale |
|---|---|
| .NET 8 EOL | November 2026 — only ~6 months out. Multi-targeting would briefly reduce friction, then become baggage on an EOL framework. |
| Consumer impact | Only the `_build.csproj` TFM has to change in consumers — **not** their production code. The build orchestrator's TFM is independent of the app's TFM. |
| Maintenance | Single target = simpler dep matrix, no TFM-conditional code, smaller test surface. |
| Enterprise signal | "Stays on supported LTS" is the right message; multi-targeting near-EOL frameworks contradicts it. |