Story: Hotfix: three reporting tables carry a tenant and no row-level security

Every build that validates the SQL tree is red:

WARNING [RLS_001] create/reporting/reporting_analytic_types_create.sql:0
  Table 'ores_reporting_analytic_types_tbl' has tenant_id but no ENABLE ROW LEVEL SECURITY found in any *_create.sql file
WARNING [RLS_001] create/reporting/reporting_report_analytics_create.sql:0
WARNING [RLS_001] create/reporting/reporting_report_run_setups_create.sql:0
Warnings: 3

The three tables arrived with the run document and analytics model, and their models declare a tenant_id without the row-level security facet every other tenant-scoped reporting table declares. The validator is doing its job: a tenant column without the policy that reads it is how one tenant comes to see another's rows.

• Each of the three models declares :rls_tenant_isolation: true in its SQL flags drawer, as its siblings do.
• Their create and drop SQL enable row-level security and carry the tenant isolation policy; the drop SQL removes it.
• validate_schemas.sh reports 0 warnings and passes, and the SQL hygiene check is clean.
• The reporting suites and the full suite pass on a database built from the new SQL.

• The facet is declared in the model rather than the SQL hand-edited: the create and drop trees are generated, and the model is where the estate states that a table is tenant-scoped.
• analytic_type's facet first went into the component-level * Flags drawer, which also carries a tablename. The SQL facet is the one under * SQL / ** Flags; only that one reaches the generated SQL. The validator caught the mistake, because the analytic-type warning survived the first regeneration.

• The three tables' other SQL: only the row-level security section is added.