fix: key users by account_id and tolerate candidate count variance

docs/logboek.md

@@ -130,3 +130,24 @@ Waarom:
 
 - Streamen maakt de wachttijd eerlijk: de eerste kaart telt, niet de
   laatste. Een afgebroken request mag geen werk laten doorlopen.
+
+### Review-fixes en de account-quota
+
+Wat ik deed:
+
+- Twee fixes uit de live-test: gebruikers-id key op het stabiele account_id
+  veld (met id als fallback), en de intent-call accepteert nu een
+  afwijkend kandidaten-aantal in plaats van hard te falen als het model er
+  34 in plaats van 35 teruggeeft.
+- Tijdens het opnemen van demo-fixtures de dagelijkse development-quota
+  van de Spotify-app geraakt: honderden searches in enkele minuten, daarna
+  QUOTA_EXCEEDED met een Retry-After van bijna 7 uur. Het systeem
+  degradeerde zoals ontworpen: een eerlijke foutmelding, geen stille
+  fallback naar verzonnen resultaten.
+
+Waarom:
+
+- De quota is per developer-account en per dag; bulk-werk zoals fixtures
+  opnemen moet dus gebudgetteerd, en het cache-ontwerp (naam-naar-id,
+  smaakprofiel) is geen optimalisatie-garnituur maar
+  noodzakelijk om binnen de quota te blijven.