Prepare Quantum Framework for quantum-php org transition with PHP 8+ baseline

[armanist]

Summary

As part of moving the framework repository from the softberg organization to the quantum-php organization, we want to establish a PHP 8+ baseline for the framework and align the codebase, CI, OpenAPI tooling, and quality gates with that direction.

This ticket covers the framework-side work needed to make that transition explicit, enforceable, and reflected in implementation style rather than only package metadata.

Goals

• Raise the minimum supported PHP version from ^7.4 || ^8.0 to ^8.0
• Align CI with the new support policy using a PHP 8.0, 8.1, 8.2 matrix
• Modernize the codebase to use PHP 8.0-era language/features where safe by running Rector with a PHP 8-targeted rule set
• Tighten static analysis by raising PHPStan from level 7 to level 8
• Migrate OpenAPI metadata from legacy Doctrine annotations to native PHP attributes where supported by swagger-php
• Update repo metadata and documentation as needed for the organization transition

Proposed Changes

1. Raise platform baseline

• Update composer.json to require PHP ^8.0
• Remove explicit PHP 7.4 support from framework policy and documentation

2. Update CI matrix

• Change GitHub Actions PHP matrix to:
  • 8.0
  • 8.1
  • 8.2
• Drop PHP 7.4 from the test matrix

3. Modernize the codebase for PHP 8+

• Review and remove 7.4-specific compatibility branches where they are no longer needed
• Use Rector to apply safe PHP 8-targeted modernization rules across the codebase
• Prefer upgrades that make the codebase explicitly aligned with the new baseline instead of only changing the Composer constraint
• Candidate Rector targets include:
  • converting remaining PHP 7.x compatibility patterns to native PHP 8-safe forms where applicable
  • removing version-bridging conditionals that only exist to support 7.4 behavior
  • normalizing constructor/property typing and nullable handling where Rector can upgrade safely
  • applying PHP 8-level code quality transformations already supported by the current Rector config
  • modernizing selected call sites and control flow only where the automated change is low-risk and improves consistency
• Concrete examples to review during implementation:
  • ob_implicit_flush(PHP_VERSION_ID >= 80000 ? false : 0) style branches
  • dependency and runtime workarounds that exist only because 7.4 remained in the support matrix
• Keep the scope focused on safe automated upgrades and consistency, not broad stylistic churn

4. Tighten static analysis

• Raise PHPStan from level 7 to level 8
• Address newly surfaced violations needed to keep the build green

5. Migrate OpenAPI metadata to attributes

• Review current OpenAPI generation flow and annotation usage
• Replace legacy @OA\... docblock annotations with native #[OA\...] PHP attributes where supported by swagger-php
• Re-evaluate whether doctrine/annotations is still required after the migration
• Update generated module templates so new modules use attributes rather than legacy annotations
• Ensure the OpenAPI generation command and related tests still pass after the migration

6. Update transition metadata and docs

• Update repository/org references that should now point to quantum-php
• Update changelog entries for the new baseline
• Update migration/release notes and support statements

Motivation

The framework is being repositioned under the quantum-php organization and should reflect a forward-looking baseline.

Maintaining PHP 7.4 support currently affects:

• Composer platform constraints
• CI matrix complexity
• dependency pinning decisions
• small runtime compatibility branches

Dropping 7.4 support simplifies maintenance and allows the framework to actually adopt a PHP 8-oriented code style instead of only advertising PHP 8 compatibility at the package boundary.

The transition also creates a natural opportunity to stop relying on legacy Doctrine-style OpenAPI annotations and move to native PHP attributes, which are supported by PHP 8 and preferred by the current swagger-php guidance.

Acceptance Criteria

• composer.json requires PHP ^8.0
• GitHub Actions runs on PHP 8.0, 8.1, and 8.2
• 7.4-specific compatibility code is reviewed and removed where safe
• Rector-based PHP 8-targeted modernization is applied with bounded scope
• The codebase reflects the PHP 8 baseline in implementation style, not only in package metadata
• PHPStan runs at level 8
• OpenAPI definitions are migrated from legacy annotations to native PHP attributes where supported
• Module templates generate attribute-based OpenAPI metadata
• doctrine/annotations is removed if no longer needed after the migration, or explicitly retained with rationale if some usage still requires it
• Changelog and documentation reflect the new PHP support baseline
• Repository/org metadata relevant to the move is updated

Notes

• This ticket is about establishing a PHP 8+ baseline, not introducing a PHP 8.1-only or PHP 8.2-only baseline.
• Dependency upgrades unrelated to the PHP 8 baseline should be handled only where necessary to support the transition cleanly.
• Rector changes should stay intentional and reviewable; avoid enabling overly broad transformations that cause large stylistic churn without clear PHP 8 baseline value.
• OpenAPI attribute migration should be kept practical: migrate real framework/template usage first, then remove Doctrine Annotations only when the remaining surface is confirmed clean.

[armanist]

OpenAPI attribute migration is intentionally deferred for this ticket.

The framework baseline is being raised to PHP ^8.0, but the installed swagger-php version (4.11.1) only enables its native PHP attribute analyser on PHP 8.1+. Because of that, converting the shipped OpenAPI metadata to
#[OA\...] attributes while still supporting PHP 8.0 would leave attribute-based scanning unsupported on the minimum supported runtime.

For this reason, the OpenAPI templates remain on Doctrine-style @OA\... annotations for now, and doctrine/annotations is intentionally retained. We can revisit the attribute migration once the framework baseline or OpenAPI
tooling path supports it cleanly.