fix(admin): lower owner-email enrichment concurrency to 2

The upstream admin gateway tolerates only a small concurrent burst; at
concurrency 4 the tail of the per-row getUserById fan-out was truncated
into empty bodies on every list load (deterministic '—'), and the retries
piled into the same throttle window. Measured 0 failures at concurrency 2
(and 1) versus consistent truncations at 4, so pin enrichment to 2.

lib/admin/list.ts

@@ -77,11 +77,15 @@ type TunnelRow = TunnelJoinRow & {
 const USER_SCAN_MAX_PAGES = 50;
 const USER_SCAN_PER_PAGE = 1000;
 
-// Resolve tunnel owner emails a few at a time rather than all at once: a large
+// Resolve tunnel owner emails a couple at a time rather than all at once. The
-// concurrent burst of getUserById calls self-inflicts an upstream throttle
+// upstream tolerates a small concurrent burst, but a large fan-out of
-// (truncated/empty bodies) that even per-call retries can't fully escape, which
+// getUserById calls (one per row, all in flight) trips an upstream throttle that
-// is what intermittently rendered owner_email as "—" under load.
+// truncates the tail of the burst into empty/partial bodies. Those truncations
-const OWNER_EMAIL_CONCURRENCY = 4;
+// arrive faster than the per-call retry window can clear them, so a few rows
+// were deterministically rendered as "—" on every list load. A low concurrency
+// keeps each lookup inside the throttle allowance; measured 0 failures at 2 and
+// consistent truncations at 4, so we stay conservative here.
+const OWNER_EMAIL_CONCURRENCY = 2;
 
 function userSortValue(u: User, sort: UserSort): string | number {
   switch (sort) {