Seed all Pokemon species and add admin pagination

- Update fetch_pokeapi.py to import all 1025 Pokemon species instead of
  only those appearing in encounters
- Add paginated response for /pokemon endpoint with total count
- Add pagination controls to AdminPokemon page (First/Prev/Next/Last)
- Show current page and total count in admin UI
- Add bean for Pokemon forms support task
- Update UX improvements bean with route grouping polish item

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

.beans/nuzlocke-tracker-f44d--add-pokemon-forms-support-to-seeding.md

@@ -0,0 +1,31 @@
+---
+# nuzlocke-tracker-f44d
+title: Add Pokemon forms support to seeding
+status: todo
+type: task
+created_at: 2026-02-06T10:11:23Z
+updated_at: 2026-02-06T10:11:23Z
+---
+
+The current seeding only fetches base Pokemon species. It should also include alternate forms (Alolan, Galarian, Mega, regional variants, etc.) which have different types and stats.
+
+## Scope
+
+1. **Data model evaluation**: Determine if Pokemon forms need a separate table or can be handled with additional fields on the existing Pokemon model (e.g., `form_name`, `base_pokemon_id`)
+
+2. **PokeAPI structure**: Investigate how forms are represented in PokeAPI data:
+   - `pokemon-form` endpoint
+   - `pokemon` endpoint (forms like `pikachu-alola` have separate entries)
+   - Relationship between species and forms
+
+3. **Seed data updates**: Update `fetch_pokeapi.py` to:
+   - Fetch all forms for Pokemon that appear in encounter tables
+   - Include form-specific data (types, sprites)
+   - Handle form naming consistently
+
+4. **Frontend considerations**: Ensure Pokemon selector in encounter modal can distinguish forms when relevant
+
+## Questions to resolve
+- Should forms be stored as separate Pokemon records or as variants of a base Pokemon?
+- How do encounter tables reference forms vs base species in PokeAPI?
+- Which games have form-specific encounters that need to be supported?

.beans/nuzlocke-tracker-qeim--ux-improvements-pass.md

@@ -11,7 +11,8 @@ The current encounter tracking and run dashboard UX is clunky. Do a holistic UX
 
 Areas to evaluate:
 - Encounter logging flow (too many clicks? modal vs inline?)
-- Route list readability and navigation (long lists, no grouping)
+- Route list readability and navigation (long lists)
+- Route grouping UX polish (auto-expand unvisited groups, remember expand state, visual hierarchy for parent vs child)
 - Run dashboard information density
 - Mobile usability
 - Navigation between run dashboard and encounters