CHEF-37625 - Add concurrent-ruby >= 1.3.8 floor across chef-server-ctl, oc-id, oc-chef-pedant, oc_bifrost-pedant Gemfiles

[lbakerchef]

NOTE

The oc-id verify failure is fixed here:
https://progresssoftware.atlassian.net/browse/CHEF-37669

Summary

Adds an explicit concurrent-ruby version floor (>= 1.3.8) directly to four Gemfiles: src/chef-server-ctl/Gemfile, src/oc-id/Gemfile, oc-chef-pedant/Gemfile, and src/oc_bifrost/oc-bifrost-pedant/Gemfile. concurrent-ruby is a real (transitive, via chef/knife/berkshelf) dependency in all four.

Scope grew from the original single-file / >= 1.3.7 plan (see first commit below) once investigation found the other three apps carry their own, separately-numbered Dependabot alerts for the same three CVEs in their own independent dependency graphs — all four are fixed together here. >= 1.3.8 (rather than the ticket's literal 1.3.7 ask) was chosen so all four Gemfiles land on one consistent value.

Declared as a bare floor rather than routed through the SafeVersions/resolve_safe_version.call mechanism (unlike rack/rexml directly above it in chef-server-ctl's Gemfile): that mechanism exists to keep a cleanup-recipe threshold (ruby_gems_cleanup.rb, in chef-server-omnibus-config) and a Gemfile floor from drifting apart for the same gem. concurrent-ruby has no on-disk cleanup consumer (no ticket or test/scan finding has established that need — live-VM testing confirmed a cleanup entry would actually break the embedded Chef Infra Client's own hard-pinned binstub, since the two share a gem root with no server/client separation), so there's no second consumer for that mechanism to keep in sync — see the companion chef-server-omnibus-config PR (documentation-only, same ticket) for the fuller rationale. oc_bifrost-pedant's Gemfile has no SafeVersions indirection at all (it isn't wired into any omnibus software definition), so a bare floor is its only option regardless.

Jira

https://progresssoftware.atlassian.net/browse/CHEF-37625

CVEs closed

GHSA-6wx8-w4f5-wwcr, GHSA-h8w8-99g7-qmvj (high), GHSA-wv3x-4vxv-whpp — flagged independently per app: chef-server-ctl (Dependabot alerts 377, 380, 383), oc-id (376, 379, 382), oc-chef-pedant (375, 378, 381), oc_bifrost-pedant (372, 373, 374).

Stacked branch note

This PR was originally stacked on top of CHEF-33469/lbaker (#4227, CHEF-35182 — the net-imap fix). #4227 has since merged (2026-08-19), so this PR's diff now reflects only this ticket's own 2 commits:

1. 7135543 — the original >= 1.3.7, chef-server-ctl-only floor.
2. c4e2b400d — expanded scope to >= 1.3.8 across all four Gemfiles (see Summary above for why).

Testing

• Lockfile-mechanism consistency (Docker, ruby:3.1.3, bundler 2.3.27): confirmed switching chef-server-ctl's floor from resolve_safe_version.call-indirection to a bare Gemfile line produced a byte-identical Gemfile.lock at the time (both forms interpolated to the same >= 1.3.7 requirement) — a zero-regression mechanism change, prior to the later 1.3.8 version bump.
• Real Vagrant/VirtualBox VM verification against the actual shipped build (Buildkite build #8418, this branch's tip):
  • Cold install: confirmed concurrent-ruby resolves to 1.3.8 with the floor active in all 3 shippable Gemfile.locks (chef-server-ctl, oc-id, oc-chef-pedant — oc_bifrost-pedant is never packaged into the omnibus artifact), and the appbundler trampoline hard-pins exactly 1.3.8 for chef-server-ctl.
  • Upgrade path: real dpkg -i + chef-server-ctl upgrade + chef-server-ctl start from the latest stable release (15.10.114) to this build. Confirmed the floor is actively applied during a real upgrade, not just present on a cold install: concurrent-ruby goes from 1.3.7/no-floor (chef-server-ctl) and 1.3.6/no-floor (oc-id, oc-chef-pedant) pre-upgrade, to 1.3.8/floored everywhere post-upgrade. Also confirmed the ruby_gems_cleanup recipe run during the upgrade touches only rexml — never concurrent-ruby — validating the no-cleanup-entry design decision on a real upgrade run, not just in source review.
• Full chef-server-ctl rspec suite (79/0) previously verified against the functionally-equivalent indirected version.