Classify invalid docker container-create requests as ConfigurationError

What does this MR do?

When the Docker daemon rejects a container-create request with HTTP 400 (errdefs.InvalidArgument) — typically a malformed environment variable exported by the job's own shell profile:

prepare environment: Error response from daemon: invalid environment variable:
=/builds/<project>.tmp

createContainer returned the error untagged, so setTraceStatus defaulted it to runner_system_failure and it counted against the runner's infra SLI.

This MR classifies container-create 400s as runner_configuration_error (maps to script_failure). Daemon 5xx and connectivity errors are left unchanged.

Why was this MR needed?

A 400 means the request was malformed — a job-config problem, not a platform failure. runner_system_failure is what operators page on, so one misconfigured project can push a shared shard past its error SLO on its own.

400 → configuration mirrors the secret-resolution fix in !6904 (merged). 5xx stays runner_system_failure: unlike an opt-in service like Vault, the Docker daemon is the runner's own execution substrate, so a daemon-side failure is a genuine system failure.

Why was this MR needed?

What's the best way to test this MR?

What are the relevant issue numbers?

• Reclassify plain errors and image-pull failures... (#39535 - closed).
• same pattern as !6904 (merged)