docs(hierarchy): revision 9 — complete the runner's importer enumeration (terra r8 F10)

The 'one live importer' claim was false: the measured production importer
set of the db migration runner has four members (Gateway database module
via the barrel, storage Postgres adapter, fleet-backlog and gateway-verify
CLI commands via literal dynamic import). The enumeration example now
names all four, the import analysis resolves literal dynamic import()
routes, and a non-literal dynamic import of the db package fails the
assertion. Injection-only consumers (schema-check) have no import edge.

docs/requirements/hierarchy-schema.md

@@ -65,6 +65,13 @@ 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.
 
+Revision 9 (terra r8 F10): revision 8 called the Gateway database
+module the runner's "one live importer today". That was false — the
+measured production importer set has four members. The enumeration
+example now lists the complete measured set, and the import analysis
+is extended to resolve literal dynamic `import()` routes, which two of
+the four members use.
+
 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
@@ -296,15 +303,28 @@ Binding on the implementing PRs (extends A1 §8.3):
    never appear on the writer allowlist. To close the laundering path,
    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
+   route hidden behind an index module is still a route — and it
-   module may be imported only by other registered modules or by
+   resolves literal dynamic imports the same way: an
-   importers named on that module's own closed importer enumeration in
+   `await import('<literal specifier>')` is an import edge like any
-   the register — operational entry points such as the
+   static import, not an evasion of the analysis (a dynamic import of
-   migration/bootstrap CLI or the Gateway's startup migration hook
+   the db package whose specifier is not a literal fails the assertion
-   (the runner's one live importer today, the Gateway database module
+   outright, because it makes the import graph unanalyzable). A
-   reached through the db package barrel, is such an entry point and
+   registered module may be imported only by other registered modules
-   is named in the enumeration, not exempted from analysis). Any
+   or by importers named on that module's own closed importer
-   import route outside the enumeration fails the assertion. Being a
+   enumeration in the register — operational entry points such as the
+   migration/bootstrap CLI or the Gateway's startup migration hook.
+   The enumeration names the complete permitted production consumer
+   set, and completeness is measured, not asserted: the migration
+   runner's measured production importer set today has four members —
+   the Gateway database module (reached through the db package
+   barrel), the storage package's Postgres adapter, and two mosaic CLI
+   commands, the fleet-backlog command and the gateway verify command,
+   both routed through literal dynamic imports of the db package — so
+   its enumeration names those four. A module that only receives the
+   runner's functions by parameter injection (the gateway schema-check
+   module takes them as arguments from the verify command) has no
+   import edge of its own and is not enumerated. 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