Let each team name its own OIDC group, not a global mapping

Team membership from single sign-on used to come from one env var,
TERDUT_OIDC_GROUP_MAPPINGS, matched against a team by name and creating
the team if none existed. That put the decision in the server's
environment rather than the team's own hands, needed a restart to
change, and let a typo in a team name silently create a stray team.

Each team now carries its own oidc_member_group and oidc_owner_group,
set by its owner (or an administrator) from the Members tab, or PUT
/api/teams/{teamID}/oidc-groups. The "highest role wins" rule
TERDUT_OIDC_GROUP_MAPPINGS used to apply across mappings now applies
across one team's own two fields: being in both makes somebody an
owner. The sync no longer creates a team by name; a group only ever
grants into a team that already exists.

This is a breaking change for anyone already using
TERDUT_OIDC_GROUP_MAPPINGS, deliberately not auto-migrated: an
OIDC-sourced membership is dropped at a user's next sign-in until its
team's owner re-sets the group. The README's OIDC section spells out
the migration and the risk of a visible access gap during it.

TERDUT_OIDC_ADMIN_GROUP and TERDUT_OIDC_ALLOWED_GROUPS are untouched --
only team membership moved. terdut-tui needs no change: it only reads
GET /api/teams and GET /api/teams/{id}/members, and neither response
shape moved.

internal/web/static/js/adminteam.js

@@ -146,6 +146,13 @@ function identityCard() {
       fact('Created', when(t.created_at)),
       fact('Members', String(t.members)),
       fact('Open incidents', String(t.open_incidents)),
+      // Read-only here: an administrator can see why a team's OIDC-sourced
+      // membership looks the way it does, but setting it is the team's own
+      // owner's call, from the Team tab.
+      ...(state.auth?.oidc?.enabled ? [
+        fact('OIDC member group', t.oidc_member_group || '—'),
+        fact('OIDC owner group', t.oidc_owner_group || '—'),
+      ] : []),
     ),
     form, err, ok,
   );