COORDINATION_GROUP has nowhere correct to go: the seam accepts only a userGroups authorization value, so filling it overloads the table every route gate reads

THE NULL IN COORDINATION_GROUP IS NOT A MISSING VALUE. It is a value that has nowhere correct to go, and the two need different answers from Elazar: a missing value is answered with a list of names, this is answered with a decision to build a table first. MEASURED IN SOURCE, src/lib/email/recipients.ts. COORDINATION_GROUP is fed directly to a vUserGroups."group" predicate. The only thing writable there is a userGroups membership value - the same table and the same column every route gate in terra iterates. So minting a coordination value means putting a row whose meaning is SUBSCRIBED beside rows whose meaning is PERMITTED, in the structure authorization is read from. ownerAppKey narrows visibility to terra; it does not change what the row IS. audit-terra-ca ruled that admin membership is authorization data and not notification-subscription data, and pm-terra-cc sustained it - this row is the STRUCTURAL half of that same finding: the conflation the ruling forbade at the query level arrives anyway through the storage. SECOND HALF, AND THE ONE THAT MAKES IT A DESIGN GAP RATHER THAN A NAMING PROBLEM: terra cannot express WHO GETS NOTIFIED ABOUT X, because there is no X. The two recipient sources - the COORDINATION_EMAILS literal and the nullable group - are both app-wide. There is one recipient set for all of terra. A second notification class with a different audience cannot be represented at all; it would be a second hard-coded constant, which is how the first one got here. WHAT THE STRUCTURE WOULD HAVE TO BE, so the decision has somewhere to land: a row per (appKey, notificationClass, userId), with fromAt/toAt like userGroups because unsubscribing must be a FACT and not a deletion, and with NO overlap with userGroups. notificationClass is the X that does not exist today. Under that shape, adding a coordinator to the class is the act that subscribes them - the property the current design claims and cannot exercise, since live terra admin cardinality is ONE (db02-terra-cc, terra_189 evidence) and at cardinality one a live read and a hard-coded address are behaviourally identical. NOTHING IS AUTHORISED TO START AND NOTHING IS BROKEN. One recipient, one class, one literal that works, and Elazar ruled on 2026-08-22 that the recipient is his own address. The value of this row is that the next person told to 'just put the group in' finds out here, rather than by minting an authorization row for a notification purpose. Parent question is TERRA-214 (who receives coordination notifications when it is not Elazar). That row asks WHO; this one says the WHERE does not exist. Answering 214 with a list of addresses keeps working; answering it with a membership rule requires this first.