warm pool of worker instances

To further reduce worker startup time, we want to maintain a pool of worker instances.

Spec
- workers can now "release" an instance when a user decided their tasks are completed.
- released instance are kept running up to N instances. N can be set from cdk.
- instances from n+1 will be garbage collected

This makes the instance acquire/release logic very complex. We have to be very careful about implementing this feature.

Start by tracing the existing worker instance acquire/release logic and the CDK configuration. Map how released instances remain running up to N, how N is configured, and how instances beyond that limit are garbage collected. Done means the lifecycle behavior is covered without leaving acquire or release paths ambiguous.

Written by the indexing model from the issue text.