Crew request polls read only pending runtime requests

[bryantderosier]

The Crew request list (CrewRuntimeRequestService.list, #308) reads the whole thread projection for every live Crew's Captain and seat threads on each Inbox poll. It only uses runtimeRequests, the two request turn-item types, and thread.{title, archivedAt}. Most polls find nothing pending, so a Crew with long-running seats pays for full projections it throws away.

#308 now reads a Crew's threads concurrently, which fixes the wall-clock cost. The remaining cost is what each read loads. A narrower read would skip loading turn items for threads with nothing pending:

• A projection-store query for a thread's pending runtime requests, used first, with the full projection loaded only when one is pending.
• That query belongs in apps/server/src/orchestration-v2 (upstream-owned). Per FORK.md it would be a small appended read, or better a J5-owned SQL read over the same projection tables if their shape is stable enough.

Raised by Tyler on #308 (review comment on CrewRuntimeRequestService.ts list).

Done when an Inbox poll against Crews with nothing pending loads no turn items, with a test that counts the reads.

[bryantderosier]

Closing for now. After the slim-down on #308/#309, the Inbox reads only while some seat thread has a pending approval, and Captain threads are excluded, so a steady state with nothing pending makes zero requests. The narrower projection read only matters for Crews with approvals pending at the moment, which I expect to be rare once #326 makes seats default to Full access. I'll reopen if polling cost shows up in practice.