fix(pokeapi): tolerate duplicate upstream resource names

[itsjavi]

Problem

pnpm build fails on every PR, including data-only ones (#4, #3 both hit it):

error: Duplicate PokeAPI item resource lookup key roseli-berry: roseli-berry, roseli-berry
  at fetchPokeApiResourceIndex (src/upstream-adapters/pokeapi/client.ts:75:19)

PokeAPI's /item/?limit=100000 now returns 2223 items with exactly one duplicated name: roseli-berry appears as both id 723 (the long-standing entry) and id 2279 (a newly added upstream duplicate row). The name index threw whenever two ids mapped to the same lookup key, so the build aborted. It only reproduces without a local .local/pokeapi cache, which is why it hits CI and not local builds.

Changes

a4fc3914 fix(pokeapi): tolerate duplicate upstream resource names

The name index now distinguishes two collision classes:

• Same name under two ids — keep the lowest id and console.warn, so roseli-berry resolves to 723, unchanged from the committed data. The comparison is explicit rather than order-dependent, so it stays stable however upstream orders the list.
• Different names normalizing to the same key (e.g. foo-bar vs foobar) — still throws. That case is genuinely ambiguous: normalization is lossy for those two names and any lookup would be a coin flip.

byId got a narrow version of the same treatment. It previously threw on any repeated id, including an identical duplicate row (same id and same name) — the same class of benign upstream glitch that broke CI. It now throws only when one id carries two different names, which has no safe resolution. No resource kind has duplicate ids upstream today (ability 373, item 2223, move 937 — zero duplicates).

Both maps keep every id resolvable, so byId.get('2279') still works; enrich-champions relies on that map for numeric championsId lookups.

New unit tests cover all six cases against a local stub server, no network involved.

aa2ab161 data(champions): add PokeAPI ids for mega stones and new abilities

Regenerated data, purely additive (+36 lines, zero deletions): pokeApiIds newly resolved for Mega Stones (clefablite → 2233, etc.) and two abilities (eelevate → 312, firemane → 313) that upstream has since added. No existing id changed. Separated from the fix so the two are reviewable independently.

c039e00a fix(pokeapi): correct misleading unmatched-resource warning

The unmatched-resource warning claimed "no Champions JSON files were written" while the files were written right after regardless. The message was the wrong half: nihillight is Champions-exclusive with no PokeAPI counterpart, so it is permanently unmatched, and skipping writes on that would mean never emitting champions JSON at all. Also renamed the private helper from ...Error to ...Warning — it is only console.warn'd, and the Error name is likely why the stale claim survived a refactor.

Verification

Full CI sequence run with .local/pokeapi absent and the cache redirected out of tree, so it fetched live PokeAPI exactly as CI does:

Step	Result
pnpm format:check	pass
pnpm build	exit 0
pnpm typecheck	exit 0
pnpm test	15 files, 7010 tests pass

Build output now carries the collision instead of dying on it:

Duplicate PokeAPI item resource name roseli-berry (ids 723, 2279); keeping id 723 for lookup key roseli-berry
Duplicate PokeAPI item resource name roseli-berry (ids 723, 2279); keeping id 723 for lookup key roseliberry
Missing PokeAPI resources; they were written without a pokeApiId.
moves: 1 missing
- nihillight (Nihil Light; championsId 920; tried id candidates nihillight; no PokeAPI resource with that numeric id)
202 abilities with PokeAPI IDs, 148 items with PokeAPI IDs, 834 moves with PokeAPI IDs, 1 unmatched

Also confirmed the new tests fail against the old code with the exact CI error, and that a4fc3914 stands alone — typecheck, tests and format:check all pass with the data commit's changes reverted.

Note for reviewers

Building at a4fc3914 regenerates exactly the data in aa2ab161, so a pnpm build at that intermediate commit leaves the two JSON files dirty. That is inherent to splitting regenerated data into its own commit.

#4 and #3 need a rebase on main after this lands to pick up the fix.