eventPublisher is optional because most consumers only use get /
search / update and never need to publish. create() does publish
organization.organization.created on the verified path and asserts
the publisher is wired — wire it in main.ts for any service that calls
create() (today: internal-dashboard's createCustomer flow).
Create a customer together with its primary organization in one transaction.
The Customer↔Organization mutual FK (customer.organization_id ⇄
organization.customer_id) means neither row can be inserted standalone
with both ends populated. This method inserts the customer (with
organizationId NULL), inserts the organization with the new customer's
id, then updates the customer to point at the organization — all inside
a single transaction. Under READ COMMITTED (the Postgres default) no
other session can observe the intermediate state: the in-flight tx
doesn't publish its writes until commit, and get()/search()
inner-join organization so a customer with NULL organizationId would
be filtered out anyway.
When organization.verificationProfileId is set, the org is created
ACTIVE and an organization.organization.created event is published
after commit — matching the deleted OrganizationAdminService.createVerified
path. When omitted, the org is PENDING_VERIFICATION and no event is
published; callers must drive verification through OrganizationService.
Customer service is special: While it can interact with multiple customers like an admin service, when used in a non-admin context, it should only be used to interact with the current customer.
get()andsearch()INNER JOIN organization oncustomer.organizationId, so customers without a primary organization (or whose organizationId no longer resolves to an organization row) do not surface from this service. Until the underlyingcustomer.organization_idcolumn is migrated to a realint references organization.idFK, this is the application-layer guarantee that every Customer returned has alegalEntityName.