feat(auth): add SSO token exchange endpoint

[sparkling]

Closes #1133.

Adds POST /api/v2/sso/exchange — accepts an external OIDC IdP access
token (validated by calling the IdP's /userinfo) and returns the
same ResponseUserLogin shape /api/v2/user/access_token and the
social-login callback already return. The frontend can write the
returned token into localStorage["ArtalkUser"].token and the widget
treats the user as fully logged-in (no popup, no admin password
prompt for admin users), exactly the same way loginByToken does
after the popup callback today.

See #1133 for the use case discussion. tl;dr: lets a surrounding app
that already has an Auth0/Keycloak/Okta session embed Artalk without
showing Artalk's own login UI.

What's in the diff

File	Change
server/handler/auth_sso_exchange.go	NEW. The handler — ~110 lines. Calls {issuer}/userinfo, extracts email, FindCreateUser, LoginGetUserToken.
internal/config/config.go	NEW AuthSSOConf{ Enabled, Issuer } struct, attached to AuthConf as SSO.
internal/config/cache.go	Regenerated via go run internal/config/meta/gen/main.go -locale en -format go -o internal/config/cache.go to pick up the new env-path mappings (ATK_AUTH_SSO_ENABLED, ATK_AUTH_SSO_ISSUER).
conf/artalk.example.yml	New commented auth.sso: block documenting the opt-in.
server/server.go	One line — registers h.AuthSSOExchange(app, api) next to h.AuthSocialLogin.

API surface

POST /api/v2/sso/exchange
Content-Type: application/json

{ "token": "<external IdP access token>" }

200 OK
{
  "token": "<artalk JWT, HS256(app_key)>",
  "user": { "id": ..., "name": ..., "email": ..., ... }
}

400  no token / no email claim
401  IdP rejected the token (non-200 from /userinfo)
404  auth.sso.enabled = false
502  bad JSON back from /userinfo
503  /userinfo unreachable

Same response shape as /api/v2/auth/email/login so the frontend's
existing loginByApiRes helper consumes it without change.

Backward compatibility

Gated off by default — auth.sso.enabled is false in the example
config, and the handler returns 404 unless both auth.enabled and
auth.sso.enabled are true. Nothing else in the codebase reads the
new fields. Existing deploys are unaffected.

Why no JWKS dependency

OIDC's /userinfo is the spec-defined way to validate an access
token at a relying party — the IdP signs the response server-side
and bounces non-200 on invalid/revoked tokens. Adding a JWKS
verifier (e.g. MicahParks/keyfunc) would let us avoid the
round-trip but pulls in a dep and a key-rotation cache I didn't
want to maintain in the same PR. Happy to follow up with JWKS as
a perf optimisation if you'd take it.

Tested against

Auth0 tenant sparklesparkle.auth0.com, running this fork in
production on Railway since 2026-05-19. The endpoint is also live
right now at https://artalk-production-4ade.up.railway.app/api/v2/sso/exchange
— a quick curl -X POST -d '{"token":"x"}' returns
{"msg":"SSO token rejected by issuer"} as expected (Auth0 401 → 401
to the caller). Real tokens from the Auth0 SPA SDK round-trip
correctly and return Artalk JWTs that the widget accepts.

Out of scope (could be follow-ups)

• JWKS-based local validation (faster, fewer external hops)
• Audience / aud claim check (currently relies entirely on
  /userinfo rejection)
• Mapping additional claims onto the user record (avatar from
  picture, etc.)

Happy to iterate on naming, location, or scope.

[qwqcode]

I've added some additional documentation, thanks for the PR! ❤️