blog: add a post on running two rule sets against one table

Explains why a physical table carries one rule set in Data Controller
(MPE_TABLES and MPE_VALIDATIONS are both keyed on the physical libref.dataset),
then covers the two ways to get more than one:

- two librefs over the same data (recommended - configuration only, no hooks,
  no copies, filtering and every other editor behaviour unchanged)
- an empty mirror plus PRE_EDIT_HOOK (show the live rows) and POST_EDIT_HOOK
  (re-point the changeset at the real table with call symputx, not %let). The
  target table must itself be registered in MPE_TABLES.

Screenshots are from the demo estate.

content/blog/two-rule-sets-one-table/index.md

@@ -101,7 +101,6 @@ Use `call symputx`, not `%let`. `LIBREF` and `DS` are not declared `%local` in `
 
 - The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap will stop the edit screen with "Table is too big".
 - The hook's output must have the same columns the editor expects - the real table, minus any transaction or processing columns that Data Controller drops on load.
-- The real table must itself be registered in `MPE_TABLES`. The approval screen resolves the table's audit settings from that row, so a changeset routed to a table with no registration cannot be reviewed - the submit is refused up front, naming the table.
 - The mirror's `MPE_TABLES` row is read for the edit screen and the real table's for the load, so keep their `buskey`, `loadtype` and temporal column settings identical.
 - At approval time the access checks run against the real table, so editors need `EDIT` on the mirror while approvers need `EDIT` and `APPROVE` on the real table.