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/README.md

@@ -11,6 +11,7 @@ engine does with it.
 | [Content reference](content-reference.md) | Every key a content repo may write, and what it does. |
 | [State machines](state-machines.md) | `aggregates.yaml`: stages, who moves a case, mail, deadlines, memberships. |
 | [Access](access.md) | How the Cedar policy is compiled from content, and who may ask it what. |
+| [Memberships](memberships.md) | Groups kept by portal itself: a membership as a case, a person as a phone number first, and the provider only saying who. |
 | [Operations](operations.md) | Releasing, deploying, adding a site, environment variables. |
 | [Filesystem routes](design/filesystem-routes.md) | Why the `questions/` tree is the router. |