docs+scaffold: engine/project split (C16-C18), aura-std, usage doc

Refine the structure per interview: aura is the reusable engine, research projects are separate external repos depending on it (C16). Add aura-std (universal standard-node tier) to the workspace; remove nodes/ from the engine (project concept). Record authoring-surface = Claude Code + skills pipeline, no embedded coding-LLM (C17), and project management = one-repo-one-project + Aura-native run registry (C18). Add CLAUDE.md invariants 9-10, code_roots -> [crates], and docs/project-layout.md documenting the day-in-the-life and project repo layout.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -80,3 +80,14 @@ design decision, not a refactor, and belongs in the ledger.
 8. **Deploy artifacts are frozen.** Hot-reload (cdylib) is an authoring-loop
    tool only. The live bot is a statically-linked, versioned, frozen artifact —
    never hot-swapped (audit trail: this bot = this commit).
+9. **Engine / project separation.** This repo is the reusable *engine*. Research
+   projects are separate external repos that depend on it. Project-specific
+   signals live in a project's `nodes/`; cross-project-reusable nodes in shared
+   crates; universal blocks in `aura-std` (shipped here). Reuse is cargo-native;
+   the hot-reload unit is always the project-side `cdylib`. No user/project
+   signals in this repo (only `examples/` fixtures for the engine's own tests);
+   no multi-project manager or node registry inside aura.
+10. **Authoring surface.** Nodes are authored in native Rust via Claude Code +
+    the skills pipeline. aura ships no embedded coding-LLM. IONOS LLMs are used
+    only as a runtime data source (news bias), with per-session consent, never
+    in the code path.