(Docker 5/5) Sweep expired suspended docker-autoscaler environments

What does this MR do?

Implements SweepRuntimeEnvironments for the autoscaler provider. Acquire passes runtime_environment_ttl to taskscaler, which stamps the slot's ExpiresAt once. The sweep expires suspended slots more than the grace past that stamp, removes their workload through ReleaseEnvironment on a running instance (taskscaler deletes a stopped instance whose slots have all expired, without starting it), and frees them. A resume of an expired slot fails as runtime_environment_unavailable.

Why was this MR needed?

Resume and the sweep must follow the expiry stamped when the environment was created, not the current TTL of whichever manager runs them. Without the sweep, a suspended docker-autoscaler environment nobody resumes holds its VM forever.

What's the best way to test this MR?

• go test -race ./executors/internal/autoscaler/ ./executors/docker/ -run 'Sweep|Release|Expir'
• e2e on GCP with backbench: the slot ExpiresAt matches the containers' expires-at label. A resume past the stamp is refused by taskscaler before the VM starts. After expiry + grace the sweep removes the environment's containers, networks and volumes on a running VM (cache volumes kept), and deletes a stopped VM without starting it. A resume within the stamp succeeds after the config TTL is lowered.

Depends on the taskscaler slot expiry stack (gitlab-org/fleeting/taskscaler!117 (merged), gitlab-org/fleeting/taskscaler!123 (merged), gitlab-org/fleeting/taskscaler!118 (merged)), all merged. Pinned to main merge commit bdd072f494f7 (v0.0.0-20261110133749-bdd072f494f7). Taskscaler has no tags yet, so there is no released version to pin.

What are the relevant issue numbers?

Related to #39468.