### Problem/Motivation Two gaps in how the API bounds what one consumer can ask of it. **1. The API limit listens on every request the site answers.** `ApiFloodSubscriber` is a `kernel.request` subscriber. On a site with `kessai_server` enabled, every request runs it: front pages, admin pages, assets served through PHP. The container builds `FloodGuard`, `RequestSource`, `ConsumerScope` and the config factory for it, and only then does it look at the route and return early on everything outside `/kessai-api/`. Its docblock defends the choice ("a subscriber rather than a check in each controller method, because there are ten of those"). Ten API doors do not justify a cost on every page of the site. **2. The doors that take a list of ids take a list of any length.** `POST /kessai-api/payments/read`, `/payments/delete` and `/payments/forget-tokens` load every id they are sent in one `loadMultiple()`. The payments door caps its subjects at `PaymentQuery::MAX_SUBJECTS` (100) for this reason. The request limit counts requests, not ids, so one request naming a million ids bypasses it. That request loads every payment it names, and the consumer whose limit was meant to stop it is the one sending it. While reading those doors, two fields are still read with a cast where every other field goes through a reader: - `handoff` is read as `$body['handoff'] ?? FALSE`. The string `"false"` is true, so the door returns a handoff link that was not asked for. `readBoolean()` exists to refuse exactly this. - `operation` on the token door is read as `(string) $body['operation']`. A list sent there raises an "Array to string conversion" warning in the log and is then answered 404. ### Proposed resolution - Replace the subscriber with an `ApiLimit` service (`refuseOverLimit(): ?JsonResponse`) that every door of `PaymentApiController` asks first. This is the shape orchestra's `DoorwayLimit` took when it dropped its own `kernel.request` subscriber. Only API requests pay for it. The refusal, the logging and the counting stay as they are. - Cap a list of ids at a new contract constant, `PaymentWire::MAX_IDS` (100), and refuse a longer one with a 400. The client sends a long list in chunks, so a caller of `getPayments()`, `deletePayments()` or `deleteStoredTokens()` notices nothing. - Read `handoff` through `readBoolean()` and `operation` through `readString()`. - In `takeTokenPayment()`, read the values once into named variables, instead of two eight-argument lines that differ only in the method they call. ### Remaining tasks - Implement, with tests: - The limit is not built on a request outside the API (container `initialized()`). - A door over the limit still answers 429. - A list over the cap is refused, and the client still reads, deletes and forgets a longer list. - `"handoff": "false"` is refused. ### User interface changes None. ### API changes - `ApiFloodSubscriber` is removed and replaced by the `ApiLimit` service. - The id-list doors refuse a list longer than 100 ids with a 400. The client chunks its own lists. - A non-boolean `handoff`, or a non-string `operation`, is refused. ### Data model changes None. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)