ci: queue pending reusable OpenTelemetry suites

[zhongkechen]

Shared OTel concurrency groups currently keep only one pending caller even with cancel-in-progress: false. Another waiting caller can therefore replace an earlier pending suite. For example, Python run 37552973990 canceled all four regular backend jobs before runner allocation while both short long-running suites succeeded.

Set queue: max on the existing suite and long-running reusable-workflow groups. This retains waiting calls up to GitHub's maximum queue length while preserving the group names and one active execution per group. The change applies to callers adopting the updated workflow revision; older or already queued workflow definitions retain their own queue policy.

Validation: 358 workspace tests with coverage, type checks, format/lint, requirement YAML lint, and wheel/sdist build and discovery checks passed. Parsed YAML comparison confirms the only changes are the two concurrency.queue values; all jobs, conditions, timeouts, failure gates, and the 20-case orchestrator remain unchanged. The current GitHub workflow schema accepts queue: max.

Related PR: #131 carries the same queue policy alongside its 24-case OTel requirements.

[github-actions]

Codex AI review

No actionable findings. Residual risk: repository tests do not assert the new concurrency queue policy, and actual queue behavior requires GitHub-hosted integration coverage.

Reviewed commit a66037abbbfa55fde97f714e30f0bc262edefd63. Workflow run