fix: add Gemini -latest aliases so a new API key can actually run the pipeline

[ayo0la]

Summary

No Gemini model in providers.json completes a request on a newly created API key. Two of the five fail with a hard 404 model-availability error, and they are exactly the two .env.example recommends.

Probed each shipped model against the same endpoint OpenAICompatibleProvider uses (POST https://generativelanguage.googleapis.com/v1beta/openai/chat/completions), with a key created today:

model	status	message
gemini-2.0-flash	429	quota
gemini-2.0-flash-lite	429	quota
gemini-2.5-flash	404	... is no longer available to new users
gemini-2.5-flash-lite	404	... is no longer available to new users
gemini-2.5-pro	429	quota

The 404s are the hard failure — those versions are retired at the model level for new keys, so no quota or billing change recovers them. I am deliberately not claiming the 429s as proven config bugs: I had spent quota on that key earlier the same day and cannot fully rule out ordinary project quota. They are listed as observed.

Why this bites new contributors specifically

.env.example recommended "gemini-2.5-pro" and "gemini-2.5-flash", and README.md used gemini-2.5-pro and gemini-2.0-flash as its worked examples. Following the README verbatim with a fresh key failed on the first run, with an error that reads like a bad API key rather than stale config.

Fix

Adds the two -latest aliases, which track the current version rather than going stale, and points .env.example and README.md at them:

• gemini-flash-latest
• gemini-flash-lite-latest

The existing dated pins are left in place on purpose. They still resolve for keys that already had access, and removing them would break those users for no benefit. The docs simply stop recommending them, and the README now notes why aliases are preferable.

This is the part that stops the bug recurring — the same retirement will hit any gemini-3.x pin in a few months.

Testing

• Both new aliases return 200 on a freshly created key against the repo's own endpoint; the five existing pins are unchanged.

• providers.json validates as JSON, and config.provider_for() resolves both new entries to the Gemini provider with the expected temperature / top_p.

• Full end-to-end run with DEFAULT_MODEL=gemini-flash-lite-latest:

  python score.py ./resume/sample.pdf --role software_engineering_intern
  

  Section extraction, evaluation, and scoring all complete and return well-formed output — 0.0/100 with coherent per-category evidence, which is the correct result for the bundled non-engineer sample resume.

Reported in #378. Fixes #378

[ayo0la]

Still reproduces on main today (2026-08-08). Re-probed every shipped Gemini model against the same endpoint OpenAICompatibleProvider uses:

model	status
gemini-2.0-flash	429 (quota, availability masked)
gemini-2.0-flash-lite	429 (quota, availability masked)
gemini-2.5-flash	404
gemini-2.5-flash-lite	404
gemini-2.5-pro	429 (quota, availability masked)
gemini-flash-latest	200
gemini-flash-lite-latest	200

Worth noting the 404 set has moved since I first filed this in July: back then gemini-2.5-flash and gemini-2.5-pro were the two hard 404s, and gemini-2.5-flash-lite was reachable. Today gemini-2.5-flash-lite 404s instead. That drift is the actual argument for the rolling aliases: whichever dated pin is listed will eventually retire, so the config needs re-editing every time rather than just working.

One note for triage, since there is overlap: #367 also touches this, but is narrower and now partly stale.

• It adds only gemini-flash-lite-latest. This PR adds both gemini-flash-latest and gemini-flash-lite-latest.
• It does not update .env.example or the README, which still recommend pinned models that 404 on a new key.
• Its config.py change (adding load_dotenv()) already landed on main via fix: load .env in config.py before env reads so DEFAULT_MODEL applies #358.

Happy to close this in favour of #367 if you would rather take that one, though that would still leave the docs pointing at models that do not resolve.