fix(FFESUPPORT-887): remediate July 2026 dependabot vulnerabilities

[aarsilv]

🤖 Generated from Claude

Remediates the 2 open Dependabot alerts (Guzzle stack) in php-sdk. Jira: https://datadoghq.atlassian.net/browse/FFESUPPORT-887

Advisories closed

Advisory	Severity	Package	Before → After
GHSA (Guzzle)	medium	guzzlehttp/guzzle	7.10.4 → 7.14.2 (fixed 7.12.1)
GHSA (psr7)	medium	guzzlehttp/psr7	2.10.2 → 2.12.5 (fixed 2.12.1)

Pulled up as deps: guzzlehttp/promises 2.4.1 → 2.5.1, symfony/deprecation-contracts 3.7.0 → 3.7.1.

Approach

composer update for the Guzzle stack — composer.lock only, no composer.json change. Guzzle is transitive via google/auth + google/cloud-core; the fixes are in-range minor bumps within those packages' ^7/^2 constraints. Supersedes the open Dependabot PRs #60 / #61 (consolidated into one).

How the tests/CI protect this change

• composer validate --strict ✓ (lock in sync with manifest).
• PHPUnit — 98 tests / 664 assertions pass on PHP 8.5.
• CI (run-tests.yml) re-runs composer validate --strict + make test.

Deferred advisories

None — both alerts addressed; none left dismissed/auto-dismissed.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aarsilv]

🤖 Response from codex:

LGTM

• composer.lock resolves guzzlehttp/guzzle 7.14.2 and guzzlehttp/psr7 2.12.5, above fixed versions 7.12.1/2.12.1; vulnerable 7.10.4/2.10.2 are absent.
• Compatible transitive bumps: promises 2.5.1, deprecation-contracts 3.7.1, and required polyfill-php80 1.37.0 all support PHP 8.1.
• Scope is clean: only composer.lock changed; all affected packages remain under packages-dev via google/cloud-storage, with no production dependency changes.
• The commit declares no deferred advisories.

(codex ran locally via codex exec read-only; relayed here — GitHub blocked codex posting directly under the sandbox.)

[aarsilv]

🤖 Context from Claude: The one red check — Package Integration Testing ("SDK Relay server failed to start") — is not caused by this PR, and it's structural, not a flake (it failed on 3 consecutive runs):

• This PR changes only composer.lock (composer.json and all src/ are byte-identical to main).
• The relay harness (sdk-test-data/package-testing/php-sdk-relay/build-and-run.sh) runs its own composer install against the published eppo/php-sdk: ^3.2 from Packagist, then cps this branch's source over vendor/eppo/php-sdk/. It never installs this PR's composer.lock, so the guzzle/psr7 bump isn't even present in the relay's runtime.
• Therefore the relay boots identically on this branch and main. This job last ran green on main on 2026‑05‑26; it has no workflow_dispatch trigger, so it hasn't re-run on main since — this is the first run in ~7 weeks, and the relay/testing‑api harness has drifted underneath it.

The actual fix is sound and verified: the SDK's own "Run Tests" job is green, composer validate --strict passes, 98 unit tests / 664 assertions pass locally, and codex reviewed it LGTM. The integration harness failure lives in sdk-test-data/testing-api, independent of this dependency bump.

[aarsilv]

🤖 Response from Claude: Fix for the Package Integration Testing failure is up: Eppo-exp/sdk-test-data#161 (bumps the php-sdk-relay harness from eppo/php-sdk ^3.2 → ^4.0; the relay was stale and booted this branch's v4.x source against v3.5.1-resolved deps). Since php-sdk's test-package.yml pins the test-server-package action @main, this PR's integration job will go green once #161 merges to sdk-test-data@main and it's re-run. The php-sdk change here is otherwise complete (Run Tests green, composer validate --strict, 98 tests, codex LGTM).

[typotter]

bumping the versions in the lockfile without an explicit floor version in the composer.json file works because these are dev-only deps which are covered by the lockfile when installed locally