Epic: AI-native build interface — make the build model and run results machine-readable

### Problem

Fallout already holds a complete model of a build in memory. The plan resolver walks the dependency graph, `ExecutableTarget` carries per-target status and tool requirements, and `[Parameter]` declares typed inputs with defaults. None of that is reachable as data.

Everything leaves the process as human-oriented console text through `Host.WriteTargetOutcome` and `Host.WriteBuildOutcome`. A caller that is a program rather than a person has to infer the build from `Build.cs` and guess at results by pattern-matching a large log. That is slow, expensive in tokens for an AI consumer, and easy to get confidently wrong — reporting "tests failed" when restore was what actually failed.

### Outcome

A machine consumer can ask Fallout three questions and get answers as data:

- What can this build do?
- What would this run do?
- What did this run do?

Plus two capabilities that make automated use safe and fast enough to be worth having: declared target effects, and target-level caching.

### Scope

| Capability | Issue |
|---|---|
| Build model as data: `describe --json`, `plan --json` | #642 |
| Durable run summary plus semantic exit codes | #643 |
| Declared target effects, gated at plan time | #644 |
| Content-addressed target caching | #647 |
| MCP server as a standalone product | #646 |

The MCP server is deliberately last. It is a thin layer over #642 (the build model as data) and #643 (the durable run summary), and building it first would mean screen-scraping the console output this milestone exists to replace.

### Already tracked elsewhere

Structured console output is covered and is not re-filed here:

- #391 (Serilog event core, Spectre console frame, NDJSON machine path) — the streaming half, with a concrete task list
- #104 (AI-friendly terse and structured output modes) — the output-mode design and its open questions
- #156 (`IOutputSink` extension point) — the plugin extension point these land on

### Notes

Every item in this milestone is a serialisation of, or a gate on, a model the engine already has. None of them needs a new execution engine. Dogfooding them also pressure-tests the `IOutputSink` and related extension points before the plugin SDK (milestone #7) makes those shapes public API.