blog: document the concurrency caveat of two librefs over one table

mp_lockanytable keys its control table on (lock_lib, lock_ds), and the
approve service takes that lock on the base table named in the submit
record. The MPE_DATALOADS staleness check is keyed the same way. So two
registrations of one physical file neither lock nor observe each other,
and a second approval can overwrite the first silently.

Spell that out, note that the hook route routes both mirrors to one base
table and so does not have the gap, and give the two ways to close it.

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

@@ -48,7 +48,7 @@ There is no copy to keep in sync, no hook to write and nothing to maintain. That
 ### Things worth knowing
 
 - Where the librefs are defined depends on your platform. On Viya, in the compute context's `autoexec.sas` (or `[DC Drive Path]/services/settings.sas`); on SAS 9, as metadata libraries or in the Data Controller Settings stored process; on SASjs Server, in `services/public/settings.sas`. The one requirement is that each library has a unique libref.
-- `mp_lockanytable` keys on `libref.dataset`, so the two menus do not serialise against each other. That has consequences beyond a collision - see [the concurrency caveat](#the-concurrency-caveat) below.
+- `mp_lockanytable` keys on `libref.dataset`, so the two menus do not serialise against each other. That has consequences beyond a collision - see *The concurrency caveat* below.
 - The audit trail and approval queue record which libref a change came through, so `ORDERS_EU.ORDERS` and `ORDERS_US.ORDERS` stay distinguishable in history. For most people that is a feature - you can see which report a change originated from.
 
 ### The concurrency caveat