Pairing limits: no shared bucket for portal calls, a cap per side

Every call through the portal arrives off the tunnel, so the per-address limit
skips those (the hub limits them by the real address), and the cap of 50 counts
and evicts portal and local requests apart, so a portal flood never pushes out
a device waiting on this network.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0138N7k5PT4dcR1iEqXaaQ9k

docs/code/api.md

@@ -192,7 +192,7 @@ on its own, so this is for reclaiming space sooner.
 | `POST` | `/dashboards/{name}/duplicate` | copy into an unpublished `{name}_copy` |
 | `GET` | `/devices/` | list devices, with `online`, `last_seen`, `report` and `reported_at` |
 | `POST`, `GET`, `PUT`, `DELETE` | `/devices/{id}` | create, read, save or delete one; a save sends the `version` it read and gets 409 when someone saved first. A read adds `io` and `bindings`, its ports as the device nodes of published flows wire them |
-| `POST` | `/devices/pair` | start device pairing, optionally with `{name, board, firmware}`; answers `code`, `secret` and the two-character `check` the device shows beside its code; unauthenticated, five a minute per address, the oldest of 50 waiting requests gives way |
+| `POST` | `/devices/pair` | start device pairing, optionally with `{name, board, firmware}`; answers `code`, `secret` and the two-character `check` the device shows beside its code; unauthenticated, five a minute per address (the portal limits its own), the oldest of 50 waiting requests from the same side gives way |
 | `GET` | `/devices/pair/{code}` | poll pairing with its `secret`; answers `device` (and `panel` for older firmware); unauthenticated |
 | `GET` | `/devices/pending` | devices waiting for a code, as they describe themselves, each with its `check` |
 | `GET` | `/devices/pair/{code}/device` | what is waiting on a code, before it is approved |