Story: System model readability

Transform the System Model from a flat component inventory into a readable architecture document that a newcomer can understand top-to-bottom. Add a narrative introduction and layer blurbs explaining the role and rationale of each architectural layer, and convert component listings into scannable tables.

• A newcomer reading the system model from top to bottom can explain what each layer does and why the system is organised this way.
• Each layer heading is preceded by a 1–2 paragraph blurb describing the layer's role, the kind of components it contains, and its dependency rules.
• Component inventories use tables (Component | Description | Dependencies) instead of bare bullet lists.
• The Database Isolation section is preserved and remains accurate.
• All id-links are valid; frontmatter #+updated is refreshed.

The current System Model at projects/modeling/system_model.org is a flat bullet list of components under four layer headings. It is accurate as a reference but does not explain the architecture — there is no narrative and no layer rationale.

The improvement follows a top-down reading order:

1. Narrative introduction. A new opening paragraph under * System Architecture (before the diagram) explains the four-layer design: Foundation provides base infrastructure with no ORE dependencies, Infrastructure adds communication and testing, Domain encodes business logic, and Application delivers user-facing surfaces. The dependency rule (layers only depend downward) is stated explicitly.

2. Layer blurbs. Each layer heading (** Foundation Layer, etc.) gains a short blurb:

   • What the layer is responsible for.
   • Why it exists as a separate layer.
   • What kinds of components live here.
   • What it depends on and what depends on it.

   The blurbs are placed before the component list so the reader has context before scanning the inventory.

3. Component tables. Each layer's bullet list converts to a table:

   • Column 1: Component (id-linked to its component_overview.org).
   • Column 2: One-line description.
   • Column 3: Depends on (other components or "none").

   The Depends on column replaces the "Depends on:" suffixes currently appended to descriptions.

4. Preserve Database Isolation. The * Database Isolation section is well-written and is kept as-is. No structural changes.

• Changing the component architecture itself (api/core/service split, dependency graph). This story is purely about documentation readability.
• Adding new components or removing existing ones from the inventory.
• Rewriting individual component_overview.org files — those are out of scope here.
• Changes to the PlantUML system diagram (ores.puml / ores.png).

Review round 1 (gemini-code-assist, 2026-05-26).