[Ticket]: flaky rate_limits_after_the_window_is_exhausted — epoch-aligned window resets mid-test

## Summary

`ingest::tests::rate_limits_after_the_window_is_exhausted` is flaky. It fails when two calls straddle a wall-clock minute boundary.

## Observation

Seen once during a full `just all-checks` run, then passed on 10 consecutive reruns:

```
assertion `left == right` failed
left: Err(IngestFailed)
right: Err(RateLimited)
```

The run that hit it touched no files in `app/lightbridge-governance` or `crates/` — `git diff --stat` against `main` for those paths was empty. Pre-existing, not introduced.

## Cause

`rate_limit.rs` computes `window = now / window_secs` — an **epoch-aligned fixed window**. The test makes two calls with `window_secs = 60`. If the first lands at `:59` and the second at `:00`, the budget resets and the second call is not throttled, so the expected `RateLimited` never happens.

Roughly a 1-in-N chance per run depending on call spacing; on CI it will surface as an occasional unexplained red.

## Suggested fix

Inject the clock (or the window index) rather than reading wall time, so the test pins the throttling behaviour instead of the alignment of the run. Do **not** paper over it with a retry — the repo's own testing rules call that out, and a retry would hide the same defect if it ever appears in production behaviour.

Worth deciding separately whether an epoch-aligned fixed window is the intended production semantics at all: it means a caller can burn a full budget at `:59` and another at `:00`.

## AI Usage Declaration

AI-assisted. Observed during an unrelated full-suite run; diagnosis read from `rate_limit.rs`. Not reproduced deterministically. A human owns intent, verification and consequences.