Close M0: headless CLI, JSON world dump, project-level plugin loading

The last piece of the agent loop from docs/kernel-contract.md §7:

- WorldDumper serializes a World to JSON — every GameObject, its
  transform, its components (arbitrary plugin-defined classes, so this
  leans on System.Text.Json's own reflection with IncludeFields=true,
  since components are public fields, not properties). Components are
  a list of {type, data}, not a dictionary keyed by type name:
  AddComponent<T>() doesn't enforce uniqueness, so a GameObject can
  carry two components of the same type, and a dictionary would throw
  on exactly that case — tested directly.
- PluginHost.LoadProject reads a project.json and resolves each
  referenced plugin id against engine + project-local search paths,
  finally putting ProjectManifest/PluginReference to use — they'd sat
  unused since the very first scaffold commit.
- Engine.Host is a real CLI now: `engine run --headless --plugins <dir>
  --project <project.json> --frames <n> [--dump <path>]`. --scene and
  --assert are explicitly rejected with a message pointing at why
  (no scene format yet — that's M2; no query DSL was ever actually
  specified for --assert, and jq over a plain JSON dump already covers
  that need), rather than silently ignored or generically rejected.
  Same for `engine diag why-pinned`: nothing has ever failed to unload
  in testing, so there's nothing to build that against yet.
- EchoPlugin now seeds one Ping-bearing GameObject in Configure() —
  sandbox.echo is documented as a test fixture, not a real subsystem,
  and there's no scene format yet to seed content any other way.

Verified by hand, not just by unit tests, since Program.cs itself
isn't covered by any: assembled a real flat plugin directory
(plugin.json + both built DLLs) and actually ran the CLI against
sandbox.echo end to end — 3 frames in, Ping.Count came back 3 in the
dump. Also checked every "not implemented" path (--scene, `diag`,
missing required args) prints its intended message rather than a
generic error.

32 tests total now (26 in Engine.Kernel.Tests, 6 in
Engine.ConformanceHarness), all green on a clean build.

README's Status section updated — M0 was the whole reason this
project exists (fast iteration without Unity's domain reload), and
that claim is no longer just architecture on paper.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N1qPfzq8TDCUMFMV3UwV5N

README.md

@@ -27,11 +27,18 @@ introspection surface no classic editor bothers with — see
 
 ## Status
 
-Pre-implementation. The current design is written up in
-[`docs/kernel-contract.md`](docs/kernel-contract.md): what belongs in the
-kernel, the plugin contract, the hot-reload model, and the build order
-(M0–M4). Nothing has shipped yet — this document is the thing to argue with
-before code gets written.
+**M0 done.** The kernel — `World` (`GameObject`/`Component`, type-indexed
+queries), `Schedule` (stage execution, conflict batching, debug-mode access
+enforcement), `PluginHost` (two-ALC load/unload, verified leak-free over
+200 cycles), and a headless CLI (`engine run --headless ... --dump`) — all
+exist and are tested. The full agent loop from
+[`docs/kernel-contract.md#7`](docs/kernel-contract.md#7-written-by-an-agent-not-a-human)
+runs end to end. No window, no rendering, no physics yet — see the build
+order (M0–M4) in [`docs/kernel-contract.md`](docs/kernel-contract.md) for
+what's next.
+
+Design and implementation are argued over in the same place: the doc is
+still the thing to disagree with before code changes to match.
 
 ## License