The embeddings policy framework attempts to rerun a repo job even if a previous
run failed at the exact same revision. This means that when a job failed, for
example because of rate limits or a problematic file, it would immediately be
rescheduled and fail again. This can be expensive and noisy.

Now, the policy framework does **not** rerun failed jobs unless the revision
changes. An admin can always kick off a job manually if they want to rerun a
job at the revision. This reduces noise and feels like a better trade-off.

#59090)

* Embeddings: refactor job scheduling code (#58787)

Refactors the repository scheduling logic into two separate methods, one used
by the GraphQL API, and the other by the policy framework. This makes the code
easier to read and lets us make some improvements:
* For policy scheduling, stop translating back-and-forth between repo IDs and
names
* Make sure to fail entire GraphQL request if there is an error fetching repos,
instead of silently ignoring it

## Test plan

Added new unit test

* Embeddings: avoid constantly rerunning job if it failed (#58980)

The embeddings policy framework attempts to rerun a repo job even if a previous
run failed at the exact same revision. This means that when a job failed, for
example because of rate limits or a problematic file, it would immediately be
rescheduled and fail again. This can be expensive and noisy.

Now, the policy framework does **not** rerun failed jobs unless the revision
changes. An admin can always kick off a job manually if they want to rerun a
job at the revision. This reduces noise and feels like a better trade-off.

* Fix compile error