queen: a deploy drain bounded by what is in flight (drain.t27, TRIOS_QUEEN_DRAIN=bounded) #1740

Part of #1712. Night-loop ledger #1729, item 2 (deploy drain). Spec: gHashTag/t27#8575 (PR gHashTag/t27#8585).

What the drain is today (measured)

• On SIGTERM, main.ts calls drainActiveRunner. The server takes no new order and waits while any bee its own runner carries still runs, up to TRIOS_BEE_RUNNER_DRAIN_SECONDS = 1800. Then it salvages the bees still running, one after another, and exits 2 s later.
• Rounds, reviews and waits run through that wait (roundsThroughDrain, BrowserOS#546). They are cut at exit.
• A bee cut at the deadline keeps its row claimed until its task lease lapses.
• Railway's RAILWAY_DEPLOYMENT_DRAINING_SECONDS = 1830 is the SIGKILL. The service has a volume, so the next container starts when this one exits.
• GitHub deployment statuses for the Queen's service, 2026-10-08 23:14Z to 2026-10-10 12:01Z: 7 of 8 deploys took 30.4-33.7 min to go live; one took 2.8 min.

Task

Add a runtime for drain.t27 behind TRIOS_QUEEN_DRAIN=bounded, off by default. On SIGTERM it:

• takes no new bee;
• holds the bees it runs until they end or the cap;
• hands back a bee still running at the cap: salvage, bundle and an ended row, side by side under one deadline;
• stops reviews at exit through turn_stop;
• leaves waits, jobs and rounds to the next process as rows.

Add tests, plus a benchmark of simulated deploys today against bounded on the same seeded swarm. Numbers go on gHashTag/t27#7851.

Railway settings are not changed. The runners (queen-runners) are not moved.