[Feature]: Horizontal scaling of agents with runtime pools

### Deployment type

Self-hosted

### What do you want and why?

Currently, agents are binded to a single runtime and tasks enqueue with a concrete runtime decided up front up. This means there's no way to horizontally scale a single agent.

Imagine I have a couple dozen developers in my team opening up tasks using the "Developer" agent. Some legacy apps may require a lot of CPU and RAM when building and running tests, so even if I vertically scale the machine, I'll get to a limit.

### Proposed solution (optional)

I don't know the internals that well, but I would explore something like:

- **Required:** Change the agents -> runtime model to agent -> runtime pool. This way, we can add more runtimes to the pool of that agent whenever needed.
- In a v1, we could still decide how to assign a task to a runtime upfront, but with some simple balancing algorithm. In a v2, ideally, we'd assign the task to the truly next available runtime.

### Screenshots / mockups (optional)

_No response_

Start by tracing how agents bind to runtimes and how tasks are assigned or enqueued with a concrete runtime. Define the runtime-pool model and balancing behavior before locating the affected Go entry points; done should include horizontally scalable agent runtimes with a clear assignment strategy and validation for concurrent tasks.

Written by the indexing model from the issue text.