…redirectUris patcher

Two related defects in the bootstrap pipeline addressed in one commit
because both touch seed-job/main.py.

## SF-1 — idempotency footgun
Added `_ensure_secret_file()` helper that validates existing content
(size + format), not just file existence. Regenerates on validation
failure; preserves on success. Applied to:
- `_ensure_jaeger_cookie_secret`: validates 44-char base64url
- `_write_client_secrets`: validates non-empty + matches live Keycloak
  secret (catches operator rotation via Keycloak UI too)
- `_ensure_admin_password_file` (new wrapper): validates 12-128 chars

Catches the PR #50 64-byte hex format bug AND any future format change
to any seed-managed secret. 10 offline unit tests pass.

## SSO-1 — Keycloak client redirectUris patcher
`seed-job/realm-mintkey.json` previously stored literal placeholder
strings like `${MINTKEY_ADMIN_API_PUBLIC_URL}/v1/auth/oidc/callback`
in client redirectUris. Keycloak does NOT substitute env vars; seed-job
did not patch them after import. Result: operator-facing login over
LAN (e.g. http://10.243.1.200:8081/) was rejected with
`invalid_redirect_uri` because no allow-listed URI matched.

Added `_patch_keycloak_client_redirect_uris(client_id_name,
callback_path, public_url_env)` called after realm import for:
- mintkey-admin-api → /v1/auth/oidc/callback / MINTKEY_ADMIN_API_PUBLIC_URL
- mintkey-grafana → /login/generic_oauth / MINTKEY_GRAFANA_PUBLIC_URL
- mintkey-jaeger → /oauth2/callback / MINTKEY_JAEGER_PUBLIC_URL

Algorithm: GET client → compute desired URIs (preserve localhost, drop
`${...}` placeholders, add public URL if env var set) → PUT only if
different. Idempotent (no-op if already correct). Logs
"patched <client> redirectUris: ..." or "<client> redirectUris already
current."

realm-mintkey.json updated: `${...}` placeholders removed from all 3
clients (the patcher now adds the correct values dynamically).

docker-compose.yml seed-job env extended to forward
MINTKEY_{ADMIN_API,GRAFANA,JAEGER}_PUBLIC_URL.

Verification (local):
- Test 1: existing-valid jaeger cookie preserved across re-runs.
- Test 2: 11-byte stale cookie → detected INVALID → regenerated 44 bytes.
- Test 3: idempotent ("valid — skipping") on second run.
- Test 4: jaeger-auth healthy after seed-job re-run.
- Patcher: 3 clients get LAN-IP URIs added; re-run logs "already current".
- Keycloak REST query confirms: no `${...}` literal remains; LAN IP +
  localhost both in redirectUris.

CI regression: low — seed-job's patcher no-ops when env vars unset
(CI integration test path). Idempotency helper is purely additive over
existing logic.

Out-of-scope follow-ups (documented in 99-report):
- `webOrigins` left at `+` (Keycloak permissive default); explicit LAN
  origin patching deferred — covers same-origin already.

Keycloak realm enforces PKCE S256 on mintkey-jaeger client (per
seed-job _enforce_pkce_on_clients), but oauth2-proxy v7.6.0 doesn't
enable PKCE automatically. Without the flag, the auth flow reached
Keycloak but returned:

  error=invalid_request&error_description=Missing+parameter%3A+code_challenge_method

Added --code-challenge-method=S256 to the exec line. Verified via
live curl chain: /oauth2/sign_in now lands on Keycloak login page
with code_challenge=... in the URL.

Same root-cause-family as PR #48 (otel-collector config drift) and
PR #52 (oauth2-proxy cookie format): config-vs-runtime expectation
mismatch surfaced once the upstream constraint became reachable.