[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.

Start with rate_limit.rs and the ingest::tests::rate_limits_after_the_window_is_exhausted test. Trace how the test obtains the window value and how the two calls are made, then run the focused test before and after the change. Done means the test controls the clock or window index and reliably expects RateLimited without retries; treat production fixed-window semantics as a separate decision.

Scritto dal modello di indicizzazione a partire dal testo della issue.