Show condition item names instead of IDs

Objective

• Show human-readable item names (not raw Mongo IDs) in rendered condition summaries so users can verify saved logic at a glance.
• Fix the primary surfaces where block condition descriptions appear today: email template blocks and agreement template blocks.
• Resolve all ID-based condition attributes in those summaries (services, inspectors, contact roles, tags, etc.), not only services.
• Keep condition evaluation unchanged — IDs remain the stored and evaluated value; only display text improves.

Background

• Product feedback (Featurebase, Slack): when reviewing saved conditions on blocks (especially in the email template editor), users see internal IDs instead of item names, making it hard to confirm what a block will show or hide.
• Examples from reports:

• What works today: conditions store and evaluate correctly using internal IDs (conditionsResolver.ts on the backend). The condition editor already shows names in pickers (ValueConditionInput.tsx — e.g. service Autocomplete displays service.name, stores service._id).
• What's broken: block summary text uses conditionToText helpers that stringify the raw value (e.g. service ids is "674abc...") with no ID→name lookup.
• Where summaries actually render today: only two places use readable condition text — BlockWrapper.tsx (email builder) and AgreementBlockWrapper.tsx (agreement templates). Action-flow cards/triggers show condition counts only, not readable descriptions.
• ATT-366 (email-block / service-name report) is marked duplicate of this ticket — implement here, not in ATT-366.
• Name resolution requirements:
• Show the current name for a stored ID when it resolves in loaded lookup data (covers renames).
• Show name only in the summary — not "Name (id)".
• When an ID no longer resolves (deleted/inactive item), show a neutral fallback label (e.g. "Unknown service") — never expose the raw Mongo ID.

Done

• Email template block condition summaries show human-readable names for all in-scope ID-based attributes.
• Agreement template block summaries behave the same way (shared helper preferred over duplicated logic).
• Deleted or unresolvable references never display raw IDs.
• Condition evaluation and stored condition payloads are unchanged.

Scope

Frontend (attik-frontend) — primary fix surface

• src/app/tools/action-flow/email-builder/[email_id]/blocks/BlockWrapper.tsx — conditionsToReadableText / conditionToText (~lines 488–560) renders block summaries; currently outputs raw value for is / is_not and similar cases.
• src/app/tools/agreements/templates/[id]/AgreementBlockWrapper.tsx — duplicate conditionToText / conditionsToReadableText; same gap applies.
• src/components/conditions/ValueConditionInput.tsx — reference pattern for ID→name resolution when editing (service-ids, inspector-id, contact-role-ids, tags, role-portal-permissions).
• src/components/conditions/templatingData.ts — attribute definitions including service-ids (conditionType: 'services', display: 'Services').
• src/components/conditions/Conditions.tsx — may already load services/inspectors/roles/tags for the editor; determine whether those lists can feed the readable-text renderer or whether a shared lookup helper is needed.

ID-based attributes to resolve in summaries (minimum checklist)

• service-ids → service name
• inspector-id → inspector name
• contact-role-ids → role name
• tags → tag name
• role-portal-permissions → permission label

Backend (attik-backend) — out of scope for display fix

• src/util/functions/actionFlows/conditionsResolver.ts evaluates conditions using raw IDs (including stale service-ID filtering via activeServiceIds); correct for execution, not for UI labels.
• No backend change required unless a future surface needs server-generated condition descriptions.

Optional follow-up (not required for initial ship)

• src/components/flowStatus/FilterReasonTooltip.tsx — flow evaluation debug UI shows raw expected / actual values; separate from block summary review UX.

Decision needed

• Extract shared conditionToText / conditionsToReadableText into one module used by both block wrappers?
• Exact fallback copy for unresolvable IDs ("Unknown service" vs "Deleted service" per attribute type)?

References

• Featurebase submission
• Slack — original report
• Duplicate (closed): ATT-366
• Email builder: attik-frontend/src/app/tools/action-flow/email-builder/[email_id]/blocks/BlockWrapper.tsx
• Agreement templates: attik-frontend/src/app/tools/agreements/templates/[id]/AgreementBlockWrapper.tsx
• Condition editor: attik-frontend/src/components/conditions/ValueConditionInput.tsx
• Evaluation (unchanged): attik-backend/src/util/functions/actionFlows/conditionsResolver.ts