docs: describe the trigger as it is

backend/migrations/20260802172300_notify_user_email_change.up.sql

@@ -38,18 +38,17 @@ EXECUTE FUNCTION notify_usr_email_change();
 -- A superadmin acting outside their workspaces resolves through `password` instead, and that row
 -- names no workspace of its own. The `*:` payload says so: the reader drops that name's entry in
 -- every workspace rather than the whole cache, which would undo the caching on an instance that
--- rewrites these rows in bulk. `COALESCE(username, email)` is the name a principal can hold,
--- matching `permissioned_as_from_email`. Confined to superadmins because they are the only
--- accounts the `usr` triggers above cannot cover.
+-- rewrites these rows in bulk. Confined to superadmins because they are the only accounts the
+-- `usr` triggers above cannot cover.
 CREATE OR REPLACE FUNCTION notify_superadmin_identity_change()
 RETURNS TRIGGER AS $$
 DECLARE
     names TEXT[] := '{}';
 BEGIN
-    -- Both columns, not `COALESCE`: `resolve_username_to_email` matches a `u/` principal against
-    -- `username` OR `email`, and whichever string the caller passed is the key it cached under,
-    -- so an account with a username can still hold a live entry under its address. Old and new
-    -- of each, because a change to either leaves the other's entry behind.
+    -- Every alias the principal can be spelled as: `resolve_username_to_email` matches a `u/`
+    -- principal against `username` OR `email`, and whichever string the caller passed is the key
+    -- it cached under, so one account can hold a live entry under either. Old and new of each,
+    -- because a change to one leaves the other's entry behind.
     IF TG_OP <> 'DELETE' THEN names := names || ARRAY[NEW.username, NEW.email]; END IF;
     IF TG_OP <> 'INSERT' THEN names := names || ARRAY[OLD.username, OLD.email]; END IF;
     INSERT INTO notify_event (channel, payload)