Members

The school's people, scoped to what this staff member is answerable for.

Owner/admin and platform staff read the whole school WITH email addresses: they administer accounts, and POST /members — the flow this same screen carries — is keyed on an email, so the column is the thing they work from.

A plain teacher reads THEIR OWN sections' students plus the school's staff, and no email addresses at all. Two separate judgements, both deliberate:

• scope — the rail one inch above this list says "YOUR SECTIONS", and the product refuses this teacher the other section's gradebook, roster and assignments (_require_group_staff). A flat school directory behind the same login is the same leak by another door: 23 students' names to somebody responsible for 12 of them.
• emails — nothing a teacher DOES here consumes one. Announcements fan out to each student's own address without the teacher ever seeing it (that is the whole point of the one compose box), a question is a DM, and adding or removing a member is _require_admin. An address the UI never uses is personal data we are storing on a screen for decoration, which is precisely what a school's data-protection review asks about. /roster has drawn this same line since it shipped ("privacy-filtered, no emails"); this is the staff-side half of it.

A teacher in a school with NO sections at all still gets everyone — the Guanajuato rule _resolve_class_scope already follows, because a school that never adopted sections must not have its people page silently blanked. A teacher in a school that DOES use sections but staffs none of them is a teacher with no class, and correctly sees staff only.