Tag transactions with the Omeda brand

[brandonbk]

Why

The first week of matchedBy data could not answer its own question.

matchedBy	omedaIdResolution	share
customerId	resolved	68.3%
email	none-supplied	30.7%
email	diverged	0.7%
email	none-active	0.3%

That 30.7% is either the genuine new-member rate (members with no stored id yet — resolves
itself, nothing to do) or a publisher that never deployed the client change (needs a dep bump).
Those need completely different responses and are indistinguishable in the current data. Adoption
sitting flat at 65–70% across four days ruled out rollout lag in aggregate, but says nothing about
any individual tenant.

The brand was the missing dimension. It already reaches the apiRequest mongo log in logRequest,
but that cannot be faceted alongside transaction attributes — which is the entire point.

Why the plugin and not the resolver

Two reasons, and the second is the important one:

1. The brand is a property of the request, not of one mutation, so recording it in
   didResolveOperation covers every operation rather than just rapidCustomerIdentification.
2. It is present on transactions that throw. A resolver-level addCustomAttributes never runs
   when the operation fails, so an errored request would carry no brand and be unattributable. That
   matters concretely here: a client sending an input field an older service does not accept fails
   at validation, before any resolver — exactly the failure mode the Deterministic Omeda customer matching on rapid identification #43 ship-order gate existed
   to prevent, and precisely when you would most want to know which tenant it was.

What it enables

-- Is any single tenant stuck at zero adoption?
SELECT count(*) FROM Transaction WHERE omedaMatchedBy IS NOT NULL
FACET omedaBrand, omedaIdResolution SINCE 1 week ago

-- Which tenants own the divergent members (the Omeda merge queue)?
SELECT count(*) FROM Transaction WHERE omedaIdResolution = 'diverged'
FACET omedaBrand SINCE 1 week ago

-- Per-tenant error attribution, which was previously impossible
SELECT count(*) FROM TransactionError FACET omedaBrand SINCE 1 day ago

The last one is a general win beyond this work: service errors have never been attributable to a
tenant.

Scope

One line plus its rationale. No schema change, no client change, no coordinated deploy. The New
Relic agent no-ops when disabled or outside a transaction, so it is inert rather than fatal. Lint
clean, 14 specs passing, schema and plugin load verified.

After merge

Bump to 1.10.2 and push the v1.10.2 tag.

🤖 Generated with Claude Code