Memberships: groups kept by portal itself, a person by phone number first

A membership is a case in the built-in portal_memberships bucket:
invited by a desk, a grants, the seed or the responsible pass; active
from the person's first sign-in, when the provider's subject, phone
number or address matches the record; removed by a desk, and invited
again after that. One record per group and person however it was
keyed, and at sign-in every record that matched learns what the
provider verified. The active memberships join the groups claim, so
Cedar sees the same parents as before.

PEOPLE_BACKEND picks Kanidm or memberships; unset, a KANIDM_API_TOKEN
means Kanidm. The NATS access service looks a person's groups up when
a question names them by sub, phone or email and lists none. The
sign-in asks for the phoneNumber scope and reads it from userinfo.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GT37Z1Xtfd9pUuQtMTg6Yt

docs/state-machines.md

@@ -87,9 +87,12 @@ also need somebody to remember to invite them afterwards.
 
 The lint requires every form filling that bucket to collect a required
 `name` and a required `email`, because by the time a desk presses
-approve there is nobody left to ask. An instance with no Kanidm
-configured grants nothing and says so in the log; the transition
-itself always stands.
+approve there is nobody left to ask. With memberships as the people
+backend a phone number does as well as an address, and the grant is a
+record in `portal_memberships` rather than a Kanidm call (see
+[Memberships](memberships.md)). An instance with neither configured
+grants nothing and says so in the log; the transition itself always
+stands.
 
 ### after