Order the records the way the system is learned

Jochen asked whether the order made sense. It did not -- it followed when
things happened to be decided, which after consolidation is fictional anyway
since record 5 alone folds decisions taken across a week.

Concretely wrong before: the domain statement sat at 8, after five engineering
rules; the constitution was scattered across 5, 12 and 17; the tiers landed at
15, 16, 21 and 22 with process records in between.

Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what
runs on them and how it gets there (9-10), how it is built (11-16), how it is
checked (17-18), how we work (19-23).

Two things made this safe rather than free. It is a permutation, not a
compaction, so the renames go through temporary names -- otherwise two files
want one slot and one is lost. And the reference rewrite is a single
simultaneous pass, because almost every number moved into a slot another number
was vacating; replacing one at a time would have cascaded and pointed things at
the wrong record while still resolving.

Verified: 284 [ADR NNNN](path) links across the repository, all with matching
text and target.

The ordering principle is now stated in 19 rather than left implicit -- the
repository already said "the numbering is the flow" about its folders, and
there was no reason for the records to be the exception.

03-DESIGN/00-as-is/02-modules-and-manifests.md

@@ -4,9 +4,9 @@ status: implemented
 code: [hal]
 updated: 2026-08-23
 decisions:
-  - 02-DECISIONS/0019-modules-and-the-graph.md
-  - 02-DECISIONS/0003-schema-changes-are-numbered-migrations.md
-  - 02-DECISIONS/0004-no-npm-workspace.md
+  - 02-DECISIONS/0009-modules-and-the-graph.md
+  - 02-DECISIONS/0013-schema-changes-are-numbered-migrations.md
+  - 02-DECISIONS/0014-no-npm-workspace.md
 ---
 
 # Modules, manifests and features
@@ -81,7 +81,7 @@ recorded in the knowledge base; both presented as "the change did not apply" wit
 ## Dependencies between modules
 
 Modules depend on each other, above all on the shared library they all build against. There is
-**no workspace** ([ADR 0004](../../02-DECISIONS/0004-no-npm-workspace.md)): each module is a standalone
+**no workspace** ([ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md)): each module is a standalone
 package consuming published dependencies, including the mesh's own.
 
 The pipeline resolves modules into dependency **levels** and completes a level before starting
@@ -96,7 +96,7 @@ since (see
 
 A module that owns state owns its migrations: numbered, written in the module's own language,
 compiled with it, frozen once they have run anywhere, and idempotent so that re-running is safe
-([ADR 0003](../../02-DECISIONS/0003-schema-changes-are-numbered-migrations.md)).
+([ADR 0013](../../02-DECISIONS/0013-schema-changes-are-numbered-migrations.md)).
 
 Two kinds exist and the distinction matters: migrations against the module's **own** local
 state, and migrations against a **provisioned** resource, which run on the node that consumes