OIDC login doesn't use PKCE, so providers that require it can't be used

Is your feature request related to a problem? Please describe.

The OIDC authorization-code flow sends no PKCE parameters. In internal/auth/auth.go, GetOIDCAuthURL builds the request as cfg.AuthCodeURL(state, oidc.Nonce(nonce)) with no code_challenge, and ExchangeOIDCToken calls cfg.Exchange(ctx, code) with no code_verifier. Checked against v6.2.0 and master.

Providers that mandate PKCE reject the authorization request outright, so listmonk can't be used with them at all. Ours enforces it for every client, and we've had to add a per-client exemption on the provider side to let listmonk log in, which rather defeats the point of having it enabled. It's worth having on its own merits too: PKCE binds the authorization code to the client instance that asked for it, so a code that leaks (a referrer header, a shared browser, a redirect to a wrong but registered URI) can't be redeemed by anyone else. OAuth 2.1 makes it mandatory for confidential clients, not just public ones.

Describe the solution you'd like

Generate a verifier in GetOIDCAuthURL with oauth2.GenerateVerifier(), carry it to the callback in an HttpOnly cookie alongside the nonce cookie the flow already sets, and pass it to the exchange with oauth2.VerifierOption().

Only do that when the provider advertises S256 in code_challenge_methods_supported in its discovery document, which go-oidc already fetches, so providers without PKCE support keep getting exactly the requests they get today. Always sending it would be simpler, and per RFC 6749 §3.1 a server should ignore params it doesn't recognise, but that seems like a bad thing to bet existing setups on.

It comes to about 70 lines across internal/auth/auth.go and cmd/auth.go, with no new settings and no schema or frontend changes. I have it working and tested locally, so I can open a PR if you're happy with the approach.