feat(auth): add generic OpenID Connect login

[obelix58143]

Adds sign-in through any spec-compliant OpenID Connect provider, so a
self-hosted instance can use the identity provider it already runs instead of
Google or GitHub. Refs #303.

Endpoints come from the provider's discovery document, so only the issuer and
the client credentials have to be configured. Everything is off by default:
without OIDC_AUTH_ENABLED nothing changes.

Security

• PKCE (S256) on every authorization request, with the challenge derived from a
  server-side verifier
• a per-request nonce that has to come back inside the ID token
• the ID token verified against the provider's JWKS, plus issuer, audience and
  expiry; the key set is refetched once on failure so a key rotation does not
  lock everyone out
• an address the provider reports as unverified can never adopt an existing
  local account
• the session id is regenerated after sign-in
• both routes are throttled

Covered by adversarial tests rather than assertion: alg=none, algorithm
confusion (HS256 signed with the provider's public key), a foreign signing key,
a foreign audience, a foreign issuer, expiry, a replayed nonce, a missing nonce,
and reuse of the same token. A control case asserts a valid token is still
accepted, and separate cases drive the real provider to prove state validation
and the PKCE binding actually run.

Logout

When the provider publishes an end_session_endpoint, logging out ends the
session there too. The response is an Inertia location visit, because a plain
redirect is followed by fetch() and dies on the provider's CORS preflight -
the browser never navigates and the provider session survives while the
application reports the user as signed out.

A post-logout redirect is only sent when OIDC_POST_LOGOUT_REDIRECT_URI is
configured: it has to match a URI registered with the provider character for
character, and providers reject the whole logout on a mismatch.

Groups

OIDC_ALLOWED_GROUPS restricts who may sign in. OIDC_ADMIN_GROUPS derives the
workspace role from group membership on every sign-in, both ways, so offboarding
happens in one place. OIDC_AUTO_JOIN_ENABLED places new users on the shared
account for single-team installs, instead of one invite per person.

OIDC_RELEASE_OWNERSHIP clears the account owner. Ownership outranks the
workspace role, so whoever holds it is permanently outside the group system;
accounts.owner_id is nullable and every check against it is a comparison, so
clearing it is a supported state where only the owner-only actions (deleting a
workspace, billing) become unavailable.

Also here

PASSWORD_LOGIN_ENABLED=false closes the password endpoints - sign-in, reset
and password registration - not just the form. It is ignored while no other
provider is configured, so it cannot lock an instance out.

Translations are English and German only. Machine-translating security-facing
strings into the other fourteen locales seemed worse than letting them fall
back until someone who speaks them translates.

Testing

67 tests in tests/Feature/Auth/OidcAuthTest.php, Pint clean. Running against
Pocket ID: sign-in, group-derived roles, auto-join and provider logout all
verified on a live instance.

[paulocastellano]

@obelix58143 you need always translate the i18n for all languages.

[obelix58143]

Done — all sixteen locales now carry the six OIDC strings and login.description_without_password, matched to the tone each file already uses.

I also checked the whole lang/ tree while I was in there: every locale is now key-for-key identical to en across all 24 files.

These are AI translations, not reviewed by native speakers — happy to take corrections on any of them.

[paulocastellano]

@obelix58143 also i think it's missing a lot of tests for this pull request.

Can you improve it please?

[obelix58143]

Both done.

firebase/php-jwt is now ^7.0 only. The lock had already resolved to
v7.1.0, so only the constraint and the content hash move — no package changes.

Tests: +21 cases, on the paths that genuinely had none rather than more of
what was already covered.

• Discovery: a document missing the endpoints we need, a response that
  isn't a document at all, an unconfigured URL, a bare issuer expanded to the
  well-known path, one that already points at it, and the fact that the
  document is fetched once instead of on every sign-in.
• A provider with no logout endpoint, and one that's unreachable — neither
  may stop anyone logging out.
• userinfo: a provider exposing none, and the merge with the ID token
  claims in both directions. Providers commonly put groups in the ID token
  only, and losing it there would silently strip everyone of their
  group-derived role — that one is worth a look.
• The subject claim (without it there's nothing stable to tie an account
  to) and the display-name fallbacks.
• The token exchange, which had no coverage at all: a valid response, one
  with no ID token, and one carrying a token signed with a key the provider
  never published.
• Linking from the settings page, including the case that matters: a
  subject already linked to another account can't be taken over.

Each new test was checked by breaking the implementation and confirming it
turns red — a green first run isn't evidence on its own. Happy to add more
wherever you think the coverage is still thin; if there's a particular area
you had in mind, say which and I'll go at that.