OIDC auth degrades on long-lived process: redirect loop while /health stays 200 (0.114.0)

## Summary

On a long-running deployment of Superposition **0.114.0** (`ghcr.io/juspay/superposition:0.114.0`), browser OIDC login (Google Workspace) entered an **infinite redirect loop** while `GET /health` continued to return **200**.

- Clearing browser data and using **incognito did not help** (server-side failure).
- **Restarting the container process** (ECS `force-new-deployment`) restored OIDC **without changing** Google OAuth client ID/secret.
- Postgres data was **not lost** — the admin UI appeared empty because authentication failed.

We suspect in-process OIDC / HTTP client state degrades after multi-day uptime. `/health` does not reflect auth readiness.

---

## Environment

| Item | Value |
|------|-------|
| Image | `ghcr.io/juspay/superposition:0.114.0` |
| `APP_ENV` | `DEV` |
| `AUTH_PROVIDER` | `OIDC+https://accounts.google.com` |
| `OIDC_REDIRECT_HOST` | `https://` (HTTPS behind internal ALB) |
| Runtime | AWS ECS Fargate (1 task) |
| Database | PostgreSQL (Aurora) |

---

## Steps to reproduce

1. Deploy Superposition 0.114.0 with Google OIDC (`AUTH_PROVIDER=OIDC+https://accounts.google.com`).
2. Leave the process running for several days (we observed failure after ~6 days uptime).
3. Open the admin UI in a browser (or incognito).
4. Observe redirect loop:

```text
GET / → 307 /admin/organisations
GET /admin/organisations → 302 Google OAuth
Google → 302 /oidc/login?code=...
GET /oidc/login → FAIL (no session cookie)
GET /admin/organisations → 302 Google again (often prompt=none)
… repeats …
```

5. Meanwhile: `GET /health` → **200** (`Health is good :D`).

---

## Expected behavior

- OIDC callback (`/oidc/login?code=...`) should complete and set a session cookie.
- User should reach `/admin/organisations` with HTTP 200 after login.
- Auth failures should be detectable via a readiness probe (not only `/health`).

---

## Actual behavior

- OIDC callback fails; no valid session cookie is set.
- Browser enters redirect loop.
- `/health` remains 200 — orchestrator keeps the unhealthy-for-auth task running.

---

## Logs (from CloudWatch, old task, ~2h before restart)

Relevant errors in `service_utils::middlewares::auth_n::oidc`:

| Message | Approx. count (2h) | File (from log target) |
|---------|-------------------|------------------------|
| `Couldn't verify claims: Signature verification failed` | 644 | `oidc.rs:138` |
| `Error user not found in cookies` | 1205 | `simple_authenticator.rs:106` |
| `OIDC: Bad csrf` | 47 | `oidc.rs:113` |
| `Failed to exchange auth-code for token: Server returned error response` | present | `oidc.rs:127` |
| `Error in decoding user : Error in claims verification: Signature verification failed` | present | `simple_authenticator.rs:97` |

Example log targets:

- `service_utils::middlewares::auth_n::oidc`
- `service_utils::middlewares::auth_n::oidc::simple_authenticator`

---

## Workaround

Restart the application process (container). Same OIDC credentials work immediately on a fresh process.

---

## Additional issue: `Authorization: Internal` not bypassing OIDC for API calls

Hyperswitch router polls Superposition using:

```http
Authorization: Internal
x-user: {"email":"platform@peachpayments.com","username":"platform"}
```

On 0.114.0 we see API requests (e.g. `POST /config`) logged as:

```text
Error user not found in cookies
```

and HTTP **302 → Google** instead of **200**.

This may be related or separate — happy to split into a second issue if preferred.

---

## Questions / suggestions for maintainers

1. Can OIDC / HTTP client state leak or corrupt over long uptime?
2. Should there be an auth readiness endpoint (beyond `/health`) for load balancers?
3. Is `Authorization: Internal ` still the correct machine-to-machine auth path in 0.114.0+?
4. Any known fixes in releases after 0.114.0? (We see v0.115.2 is latest.)

---

## Version

- **Superposition:** 0.114.0 (`ghcr.io/juspay/superposition:0.114.0`)
- **Reporter:** Peach Payments