fix(pokedex): open detail cards without a per-card round trip

Since the grid transport change, opening a Pokémon fetched
/api/pokedexes/[id]/entries/[entryId]. That request re-scanned the whole
dex to authorise one entry, on top of an auth call and an ownership
query, and production runs its functions in a different region from the
database — so each card took seconds to fill in. The page's 60-second
reconcile also wiped the detail cache, making cards refetch about once a
minute.

Details are catalog text plus personal notes, so the dex is now read once
per account/dex in the background at the interactive/idle boundary and
fills that cache; a card opens straight from memory. That read reuses the
existing combined-data endpoint, which gains an opt-out for its count
query since a caller taking every row already knows the total.

The per-entry endpoint stays as the fallback for a card opened before the
background read lands, and now checks membership for the single entry
instead of materialising the dex. Catch status still comes from the live
grid row and any queued write, so a cached detail cannot show stale
progress.

The packed grid transport and virtualised rendering are unchanged.

tests/bdd/features/performance.feature

@@ -14,6 +14,12 @@ Feature: Signed-in page speed
     Then its entries appear within 5 seconds
     And the browser did not request the grid separately
 
+  Scenario: A Pokémon's card opens from data the browser already has
+    When I load the Pokédex page directly
+    And the Pokédex has finished loading its details in the background
+    And I open the first Pokémon
+    Then its details were already in the browser
+
   Scenario: Moving between my Pokédex list and a Pokédex is quick
     When I switch between my Pokédex list and the Pokédex
     Then each switch finishes within 3 seconds