AI-friendly default console output (terse/structured mode)

## Problem

Default build output is verbose and human-oriented — banners, ANSI colour, per-tool stdout firehose, repeated headers. When an AI agent (Claude Code, Copilot CLI, Cursor, etc.) runs `./build.ps1`, most of the output is noise that burns context tokens without adding signal. Humans tolerate it; agents pay for every line.

## Proposal

Make the default output mode terser and more structured. Add an explicit mode switch (flag and/or env var) to opt back into the rich rendering for interactive use.

Strawman:

- `FALLOUT_OUTPUT=human|ai|json` env var, plus `--output human|ai|json` CLI flag.
- `ai` (default in non-TTY / `CI=true`): one line per target with status + duration, suppressed tool stdout, surfaced only on failure. No ANSI. Stable, greppable shape.
- `human` (default in interactive TTY): today's rendering — banners, colour, streamed tool output.
- `json` (opt-in): line-delimited JSON for tools.

## Why now

v12 is already a refactor wave (plugin SDK foundation + extension-point catalogue from [RFC #2](https://github.com/ChrisonSimtian/Fallout/issues/98)). The output-sink extension point is one of the listed catalogue items; this issue is the consumer-facing surface of that work.

## Open questions

- Default-mode selection rules: TTY vs `CI=true` vs explicit flag — which wins?
- Relationship to the existing `--verbosity` levels (Quiet/Minimal/Normal/Verbose). Are modes orthogonal to verbosity, or do modes preset verbosity?
- Tool wrappers (`DotNetBuild` et al.): capture-and-replay-on-failure for `ai` mode, or always stream?
- Schema for `json` mode: stable? versioned? what's the minimum useful payload for an agent?
- Does this become the canonical first-party `IOutputSink` implementation that lands with [RFC #2](https://github.com/ChrisonSimtian/Fallout/issues/98)?