#2001 SSO: SAML assertion attributes are never logged or persisted — cannot tell whether the IdP sent groups

Type: Bug Source: swamp-club (SSO / SAML)

Summary

On an SSO login we persist nothing about the assertion we received — no log line, no stored artifact carrying the parsed attributes. When user.idpGroups ends up empty, we cannot distinguish:

1. the IdP did not send a groups attribute (customer-side IdP misconfiguration), from
2. we received groups and failed to persist them (our bug).

Both produce an identical database state. There is currently no way to tell them apart from our side.

Evidence

• The ssoProvider record for the affected tenant maps extraFields: {"groups": "groups"}, so we expect the attribute to arrive.
• SSO account documents carry only: _id, accountId, providerId, userId, accessToken, refreshToken, createdAt, updatedAt, providerUsernameResolveFailedAt. No idToken, no profile blob, no raw assertion.
• Across all users in production, exactly one has a non-empty idpGroups. That record was written four days before the tenant SAML signing certificate was issued, so it did not come from an assertion. We therefore have no positive evidence that any assertion has ever carried groups.
• SSO logins do update the account row (updatedAt moves) while leaving the user row untouched — so we know the callback fires; we just keep nothing from it.

Impact

Blocks root-causing #1947. Every SSO-provisioned user on the affected tenant has an empty idpGroups, so every idp-group: grant on their self-hosted swamp serve evaluates to DENY. Because we log nothing, the only available next step is to ask the customer to audit their own IdP configuration — we cannot answer "what did we actually receive?" ourselves.

Asks

1. Log parsed assertion attribute names (and group values) at the SAML callback, per provider. At minimum, enough to answer "did the IdP send groups?"
2. Persist the resolved group list with a timestamp on every SSO login, so "never written" is distinguishable from "written once and stale".
3. Expose resolved IDP groups via swamp auth whoami and/or an admin lookup. This is question 2 in #1947 ("Is there a way to inspect what IDP groups the server has resolved for a specific user's token?"), still unanswered.

Related: #1947, #1819