Platform Person role filters need domain-backed role presence for Lead, Student, Coach, and Client

Why

Platform's operating surface now has a read-only Person search view. The first pass added four operator-facing role chips: Lead, Student, Coach, and Client. The UI shape is right, but the underlying role presence still needs to be worked into the domain data model boundaries cleanly.

This should not become a Person-field shortcut. Per ADR-0003 and the Identity Contract, Person remains canonical identity. Lead, Student, Coach, and Client are role or participation facts owned outside the Person row. Platform should derive these badges from domain role records or from an agreed projection, not store them as mutable Person attributes.

What

Current Platform implementation derives what it can see:

• Lead is intended to come from Sales role records with a person_id.
• Student is intended to come from Delivery Participant or Student role records with a person_id.
• Coach is intended to come from Delivery Coach role records with a person_id.
• Client currently maps to Platform tenancy presence as the closest identity-owned participation signal, but this may need a better name or source if Revenue or Sales owns the more useful operator meaning.

The open follow-up is to make the role-source mapping explicit enough that the Platform app can show these chips without guessing table names or leaning on legacy tables. This can be a small shared projection, a contract note, or a domain-specific read model exposed to Platform. The important part is that the role badge is derived from the domain-owned role record and remains explainable to an operator.

Asks

No immediate response required. When we return to the Platform operating surface, Platform should confirm the role-source mapping with Sales and Delivery before treating the chips as authoritative.

The next implementation pass should answer:

• Which Sales table or API is authoritative for Lead presence by person_id.
• Which Delivery table or API is authoritative for Student presence by person_id.
• Which Delivery table or API is authoritative for Coach presence by person_id.
• Whether "Client" should remain Platform tenancy, or whether the operator-facing label should come from a domain-owned customer/client role.

References

• ADR-0003 Person canonical entity.
• contracts/identity/validation/person-graph.md.
• Platform operating surface route: /platform/identity.