Experts (AdminUser) and customers (Customer) sign in to the same apps by mobile
but live in different tables, so the database cannot make the number unique
across them. A number could be given to an expert and to a customer, and the
login then silently merged the two (the customer row was adopted as the expert's
trading account), which left the expert on a customer session and the panel's
name edits unreachable.
The reference rejected a duplicate at entry (`unique:customers`, the agent being
a customers row too); this does the same where a number is typed in:
- customer create/update (wholesale, banker, walk-in): refused when an ACTIVE
expert holds the number;
- expert create/update: refused when a customer holds it (the expert's own
trading account excepted);
- the app's self sign-up: refused when an active expert holds it.
Only a number being created or CHANGED is checked, so existing duplicates keep
signing in and stay editable; the login's "expert wins" adoption is untouched.
Plain equality on the two unique columns, normalised with faToEn, so both
lookups are index hits.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
