Seat renames done; 0118 was wrong that it was a migration

A holding is derived at resolution from manifests, never stored, so there
are no recorded old names to rewrite. The work is an edit plus a kept rename
table — kept because a module lives in its own repository and may be
registered long after the catalogue stopped using an old name.

02-DECISIONS/0118-a-module-declares-its-own-seats.md

@@ -120,6 +120,21 @@ protocols is the failure nobody could diagnose afterwards.
 - **A holder must satisfy the protocol.** A claim whose module does not serve what the seat
   declares is refused at assignment, not discovered when a caller times out.
 
+## Progressive insight
+
+> **Progressive insight — 2026-09-26.** *A seat rename is not a data migration.* This record's
+> consequences say "a rename is a migration, not an edit: existing assignments hold the old
+> names, so the change carries a mapping and is applied once". Implementing it showed there is
+> nothing stored to migrate: a seat's holding is **derived at resolution** from the claims in
+> manifests (`resolve.go` builds it each time), never written down, so no recorded name is left
+> pointing at the old one. What exists is source — the controller's seat table, the manifests
+> that claim them, and a manifest that may be registered later from its own repository. So the
+> change is an edit plus a **kept** rename table, which tells a manifest written against an old
+> name what it became rather than refusing it as unknown.
+>
+> The decision — that modules declare seats, that the mesh reserves `mesh-*`, and that the ten
+> are renamed — is unchanged. Only the shape of the work was wrong.
+
 ## References
 
 - [ADR 0110](0110-a-seat-is-a-module-assignment-from-a-closed-set.md) — superseded here; its