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/getting-started.md

@@ -16,7 +16,11 @@ reads that and does the rest at start.
   ([Operations](operations.md) has adding a site).
 - A Kanidm of the site's own. Group names below are exactly the ones
   the content uses, with no prefix; that is only safe when the Kanidm
-  serves this site alone.
+  serves this site alone. (Or no Kanidm at all: with
+  `PEOPLE_BACKEND=memberships` portal keeps the groups itself and any
+  OIDC provider that can say who someone is will do; see
+  [Memberships](memberships.md). The rest of this page is the Kanidm
+  way.)
 - Mail: `mail: { from }` in `site.yaml`, and gdo on the host. Without
   it accounts are still made, but nobody hears about them.