docs(design): C30 — stability discipline: artifacts stable, code movable

Decide #296: no Rust-API stability before 1.0 (no semver, no shims; the
workspace version communicates nothing). Two consumer classes with two
mechanisms — native node crates ride the engine checkout as path deps
(what the scaffolder already emits), external embeddings pin a rev. The
compatibility promise attaches to the artifact plane (C18/C29/invariant
8), never to Rust API, with an erosion guard against 'stable API' claims.

The skeptic pass surfaced that a frozen 0.1.0 disarms the cdylib
handshake's CORE_VERSION refusal; the contract commits the load seam to a
build-identity fingerprint instead (transition tracked as #348).
Decision minutes: #296 (options a-e, rationale).

closes #296

docs/project-layout.md

@@ -91,6 +91,15 @@ deploy, spanning both halves.
 > nodes new` scaffolder emits this line; a hand-rolled node crate adds it
 > itself.
 
+> **Compatibility across the seam
+> ([C30](design/contracts/c30-stability-discipline.md)).** The node crate
+> consumes `aura-core` as a *path* dependency into the engine checkout —
+> the pair moves together, and cargo rebuilds the crate when the engine
+> changes. No Rust API stability is promised before 1.0: an external
+> embedding in its own repo instead pins the engine as a git dependency at
+> a rev, and the load handshake refuses a dylib built against a different
+> aura-core.
+
 ## Where reusable nodes live (three tiers)
 
 Everything that plugs into the engine is fractally a `Node`. Reuse is plain