feat: add on-demand clearance refresh mode

[EmmaStoneX]

Summary

• add an on_demand Cloudflare Clearance mode
• reuse the current Clearance until an upstream rejection explicitly invalidates it
• skip scheduled FlareSolverr browser solves while preserving manual and flaresolverr behavior

Problem

Managed Clearance currently refreshes eligible egress nodes on a fixed schedule. Console scopes share the browser Clearance surface, so Console-only deployments can still invoke FlareSolverr even when no Grok Web accounts are enabled.

Each refresh starts a browser, visits grok.com through the selected proxy, and attempts to solve the Cloudflare challenge. Failed solves can be retried shortly afterward. The resulting CPU usage is mostly attributed to FlareSolverr, Chromium, and proxy containers rather than the gateway that scheduled the work.

Solution

The new on_demand mode keeps the existing Clearance lifecycle but changes when the solver is invoked:

1. normal lease acquisition reuses the persisted or account-bound Clearance
2. expiration alone does not invoke FlareSolverr
3. scheduled RefreshDueClearances calls do not solve a new Clearance
4. a recoverable upstream 403 invalidates the active Clearance through the existing Lease.InvalidateClearance path
5. the next lease acquisition invokes FlareSolverr and persists the refreshed result

Existing singleflight and distributed locking continue to deduplicate concurrent refresh attempts.

Existing modes remain unchanged:

• manual: never invokes FlareSolverr
• flaresolverr: proactively refreshes stale Clearance
• on_demand: invokes FlareSolverr only after explicit invalidation

Test plan

• go test ./internal/infra/config ./internal/infra/egress
• go test ./internal/infra/provider/console ./internal/application/gateway ./internal/app
• verify normal Console acquisition does not call the solver
• verify invalidation refreshes and persists a new Clearance
• verify background refresh does not call the solver in on_demand mode