Feature: Add OpenID Connect auth

[Kogoro]

Adds optional OpenID Connect (OIDC) authentication to Glance alongside the existing local username/password flow. My problem with the current username/password flow is that on one of my notebooks I cant have a good password manager installed/used. Using a OIDC provider solves pretty much all my hassle and glance still has the same functionality for one dashboard.

Users can sign in via any standard OIDC provider (Keycloak, PocketID, Authelia, Google, etc.) using a "Sign in with SSO" button on the login page. After IdP authentication, Glance issues the same HMAC session cookie used by local login.
The feature can be used alone or together with local users. I limited the scope to OpenID only, as that's all that is really needed.

As I am currently time-constrained, the PR is authored with the help of Cursor and CE-Skills. Keep that in mind. If it is not the direction glance should/will be heading, it's ok to close the PR.

Configuration

auth:
  secret-key: ...
  oidc:
    issuer: https://auth.example.com/realms/home
    client-id: glance
    client-secret: ...

Register redirect URI: {base-url}/auth/oidc/callback
Optional flags: auto-login, disable-local-login, redirect-url

Implementation notes

Authorization code flow with PKCE, signed state cookie, nonce validation, and ID token verification via go-oidc
Shared rate limiting and cookie helpers with existing local auth
Config hot-reload re-inits the OIDC provider like other auth settings
Login UI supports SSO-only, local-only, or both

Test plan

• OIDC-only login against a test IdP (Keycloak / PocketID / etc.)
• Redirect URI works with and without server.base-url
• Works behind reverse proxy with server.proxied: true
• Local + OIDC login both work when users and oidc are configured
• disable-local-login: true hides username/password form
• Failed OIDC callback shows error on login page (?error=oidc)
• Logout clears session cookie
• go test ./... passes

One line worth calling out for reviewers: OIDC user sessions are tied to in-memory sub → hash mappings, so they don't survive a config reload until the user signs in again (same pattern as removing a local user from config).