fix(queen): every bound on keys and pools said nothing when it bound, so stop counting to a number

[dmitrii-f-t27]

Why

The operator wants to connect credentials and run bees without an upper edge in code. After #484 and #485 the bounds were 1024 keys per pool, 8 pools and a worker ceiling of 1024. Each of them fails the same way the old 16 did: the next variable past the bound looks configured in an editor and is read by nothing, and a clamp reports nothing when it clamps.

What changes

• Keys are read from the environment, not counted to a number. keysFor() asks which suffixed variables exist and takes them in numeric order (17 before 1024 before 4096), the unsuffixed name first, so every key_index already written still names the same key. A suffix must be a plain integer of two or more; _1, _02 and _x are ignored rather than guessed at.
• Pools are discovered the same way, not counted to eight.
• What is left is arithmetic, not policy. A pool is cut at MAX_KEYS_PER_POOL = POOL_KEY_STRIDE - 1 (9999) because the next pool's durable index begins at the stride, and that stride is already in production rows, so it does not move. A pool number above MAX_POOL_NUMBER cannot be addressed by a 32-bit key_index; endpointPoolProblems() reports it instead of dropping it silently.
• The worker ceiling moves from 1024 to WORKER_SANITY_BOUND = 1_000_000 in the three places that must agree: queen-dispatch.ts and the two byte-identical QueenDelegation.swift copies.

This reverses a choice from this morning

The 1024 clamp was kept deliberately as a typo guard, so here is the argument against it. An operator who meant 50 and typed 5000 over two thousand connected lanes got 1024 bees instead of 2000, and either number ends a container sized for fifty. A mistyped value is already bounded by the credential list, because dispatch refuses when every lane is taken. The constant now only stops a value that is not a number of bees at all. The default of four and TRIOS_QUEEN_MAX_WORKERS as the operator's control are untouched. If you still want a tighter guard, say which number and what it protects, and I will put that in instead.

Not claimed

That one container can run thousands of bees. Memory, worktree disk, the GitHub API quota, the review backlog and the supply of eligible issues bind long before any of these numbers. Observed today: capacity 32, and /queen/status answered healthy_idle with no-eligible-work - the swarm was limited by work, not by keys or ceilings. This change only guarantees that none of the limits is a constant in this file.

Verification

• bun test tests/api/queen-dispatch.test.ts: 87 pass, 0 fail (82 before). New cases: numeric ordering of suffixes, names that only look like key variables, the cut at the stride, a ninth pool, a pool number no index can address, 5000 requested over 9999 credentials answers 5000, and queenWorkerLimit() still refuses 99999999999, many, 0 and unset.
• The 30 test files that import dispatch, tick or public status: no new failures against the baseline I recorded before feat(queen): a second provider's keys had nowhere to go, because one URL was the whole pool #484 (the remaining failures come from my sparse checkout).
• bun run typecheck clean; biome check shows only the two pre-existing complexity warnings.
• The two Swift copies are byte-identical (cmp). I cannot build queend here, so make queen-core-sync and make queen-core need to run where Swift for Linux is available. The Swift change is one literal and its comment.

🤖 Generated with Claude Code