docs: hierarchy schema revision 7 — infrastructure register for legitimate non-hierarchy raw execution (terra F9)

docs/requirements/hierarchy-schema.md

@@ -50,6 +50,14 @@ runtime code-construction primitives; the detection claim is scoped
 honestly to the stated syntactic forms, with evasions beyond static
 reach assigned to §5.1 review/audit rather than claimed for CI.
 
+Revision 7 (terra r6 new F9): the false-positive remedy no longer
+contradicts the composition rules — legitimate non-hierarchy raw
+execution (e.g. the db package's migration runner) is dispositioned
+onto a second closed enumerated list, the infrastructure register,
+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.
+
 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
@@ -271,14 +279,28 @@ Binding on the implementing PRs (extends A1 §8.3):
    allowlisted; and an allowlisted module MUST NOT export a function
    that executes caller-supplied SQL (such an export is itself a
    raw-execution primitive, and the exporting module is treated as
-   unallowlisted for prong (iii) if it does). Runtime code-construction
+   unallowlisted for prong (iii) if it does). Legitimate raw execution
+   that is not a hierarchy writer — e.g. the migration runner in the
+   db package — lives on a second, separately enumerated
+   **infrastructure register**, distinct from the writer allowlist and
+   equally closed. A registered module is exempt from prong (iii) only:
+   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
    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
-   false positive (e.g. a table name in a non-write query string, or a
-   legitimate raw query elsewhere in the codebase) is resolved by
-   extending the allowlist in the same PR, never by weakening the
-   assertion. The allowlist is closed, and the assertion's detection
+   false positive is resolved in the same PR by adding the module to
+   the one enumerated list its role permits — the writer allowlist for
+   a hierarchy command/repository module, the infrastructure register
+   for non-hierarchy raw execution — never by weakening the assertion,
+   and neither list may take a module the composition rules bar from
+   it. Both lists are closed, and the assertion's detection
    claim is exactly its prongs: it statically surfaces every writer
    expressed as a schema-symbol reference, a class-table SQL literal, a
    raw-execution call site, or runtime code construction. An evasion