#9266: fix(gateway): configure nested lane concurrency to prevent sessions_send timeout

## Problem `sessions_send` times out when sending to idle sessions because `CommandLane.Nested` defaults to maxConcurrent=1, creating a bottleneck. ## Solution Configure the nested lane with concurrency 8 (same as subagent lane) in `server-lanes.ts` and `server-reload-handlers.ts`. ## Root Cause The nested lane is used by `sessions_send` for inter-agent messaging. Without explicit configuration, it defaults to 1 concurrent operation, causing timeouts when multiple sends occur or when waiting for responses. ## Testing - Verified sessions_send no longer times out on idle sessions - Tested concurrent sessions_send calls work correctly --- **Change Proposal:** CP-2026-02-04-014 **Approvals:** Matt ✅ Security, QA ✅ Design <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR addresses `sessions_send` timeouts by explicitly configuring the gateway command queue’s `nested` lane concurrency to 8 (matching the subagent lane). The concurrency is set during normal gateway startup (`src/gateway/server-lanes.ts`) and also applied on config hot reload (`src/gateway/server-reload-handlers.ts`). A workspace-worker memory note documents the investigation and rationale. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge after fixing a small consistency issue in hot reload lane configuration. - The change is localized to queue lane concurrency wiring and matches existing concurrency patterns (subagent=8). The main remaining issue is a hardcoded value in the hot-reload path that can drift from the startup default, leading to inconsistent runtime behavior after reloads. - src/gateway/server-reload-handlers.ts <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!} <!-- /greptile_comment -->