docs: hierarchy schema revision 8 — re-export-aware import analysis, per-module importer enumeration (terra F9 residual)

docs/requirements/hierarchy-schema.md

@@ -58,6 +58,13 @@ exempt from prong (iii) only, still bound by prongs (i)/(ii), barred
 from the writer allowlist, and importable only by registered modules
 or the operational entry points.
 
+Revision 8 (terra r7 residual F9): the register's import rule made
+satisfiable by the live tree — imports are checked re-export-aware
+(package barrels followed), and each registered module carries its own
+closed importer enumeration, which may name operational entry points
+such as the Gateway's startup migration hook; named importers stay
+subject to prongs (i)/(ii) and gain no writer standing.
+
 Scope: the tenancy/authorization structure record class — companies,
 estates, platform-projects, workspaces, hierarchy grants, their parentage,
 and constraints. Out of scope: the RBAC grant vocabulary and evaluation
@@ -287,11 +294,21 @@ Binding on the implementing PRs (extends A1 §8.3):
    prongs (i) and (ii) apply to it with no exemption, so it can hold no
    class-table schema symbol or class-table SQL literal, and it can
    never appear on the writer allowlist. To close the laundering path,
-   the same assertion checks imports: a module on the infrastructure
-   register may be imported only by other registered modules or by the
-   enumerated operational entry points (migration/bootstrap CLI), never
-   by Gateway or application sources — an import from anywhere else
-   fails the assertion. Runtime code-construction
+   the same assertion checks imports, and the import analysis is
+   **re-export-aware**: it follows package barrels and re-exports, so a
+   route hidden behind an index module is still a route. A registered
+   module may be imported only by other registered modules or by
+   importers named on that module's own closed importer enumeration in
+   the register — operational entry points such as the
+   migration/bootstrap CLI or the Gateway's startup migration hook
+   (the runner's one live importer today, the Gateway database module
+   reached through the db package barrel, is such an entry point and
+   is named in the enumeration, not exempted from analysis). Any
+   import route outside the enumeration fails the assertion. Being a
+   named importer confers nothing else: the importer stays fully
+   subject to prongs (i) and (ii), gains no writer-allowlist standing,
+   and whether it uses the registered module beyond its operational
+   purpose is a §5.1 review question, not a static claim. Runtime code-construction
    primitives (`eval`, `new Function`) anywhere in the scanned sources
    fail the assertion outright, allowlist or not. Schema definitions
    and generated migrations are excluded from the literal prong; a