Fix build-test CI failure by pinning doctrine/instantiator to PHP 8.2-compatible lock version

[Copilot]

build-test failed during composer install because composer.lock pinned doctrine/instantiator to 2.1.0, which now requires PHP ^8.4, while the workflow runs on PHP 8.2.x. This PR restores lockfile compatibility with the CI runtime.

• Root cause

  • doctrine/instantiator in composer.lock resolved to 2.1.0 (php: ^8.4), creating an unsatisfiable platform constraint in CI.

• Targeted lockfile correction

  • Updated only the doctrine/instantiator package entry in composer.lock to 2.0.0 (php: ^8.1).
  • Aligned associated lock metadata (source, dist, support URL, package require-dev, timestamp) to the selected version.

• Scope

  • No production PHP code changes.
  • No dependency graph expansion; this is a surgical lockfile compatibility correction.

{
  "name": "doctrine/instantiator",
  "version": "2.0.0",
  "require": {
    "php": "^8.1"
  }
}

[boonebgorges]

@copilot Thanks for this. Would it be simpler or more secure if we instead bumped the CI requirement to PHP 8.4+?

[Copilot]

@copilot Thanks for this. Would it be simpler or more secure if we instead bumped the CI requirement to PHP 8.4+?

I’d avoid that in this fix. Bumping CI to 8.4 would stop testing compatibility on the current workflow runtime and could mask breakage for users running older supported PHP versions. The lockfile correction is narrower and keeps the existing compatibility target intact. If we decide to officially raise the project’s minimum PHP version, we can do that in a separate PR and then let the lockfile float forward.