fix(mysql): inject /std:c17 for PHP 8.7 headers in the TS build

The TS job overlays our 8.7.0-dev headers onto the official 8.6.0RC3
QA phpize base. PHP 8.7 Zend/zend_portability.h requires
__STDC_VERSION__ >= 201112L ("Zend requires C11 or later", C1189) but
the 8.6-era build system never passes /std: to cl.exe, so nmake failed.

When the selected own-release series is >= 8.7 the build task now sets
_CL_=/std:c17 /experimental:c11atomics (the exact flags php-src
master's confutils.js ADD_SOURCES adds for VS) - the documented MSVC
env var that cl.exe appends to every invocation. The NTS variant is
built entirely from one QA era and is unaffected.

fix(mysql): inject /std:c17 for PHP 8.7 headers in the TS build

The TS job overlays our 8.7.0-dev headers onto the official 8.6.0RC3
QA phpize base. PHP 8.7 Zend/zend_portability.h requires
__STDC_VERSION__ >= 201112L ("Zend requires C11 or later", C1189) but
the 8.6-era build system never passes /std: to cl.exe, so nmake failed.

When the selected own-release series is >= 8.7 the build task now sets
_CL_=/std:c17 /experimental:c11atomics (the exact flags php-src
master's confutils.js ADD_SOURCES adds for VS) - the documented MSVC
env var that cl.exe appends to every invocation. The NTS variant is
built entirely from one QA era and is unaffected.

fix(imagick): match asset names ending in -nts in the release asset t…

…able

The case pattern '*-nts-*' did not match non-AVX2 NTS asset names that
end in '-nts' (e.g. imagick-php8.6-vs18-x64-nts), so their table row
was labeled "Thread Safe". Match both '*-nts' and '*-nts-*'.

feat: universalize builds for any PHP version, rename repo to php-win…

…dows-builds

php/php-src master bumped to 8.7.0-dev after the PHP-8.6 release branch
was cut, so the php86-windows-builds name and the version-coupled
workflow were no longer accurate. The repository is now version-
agnostic end to end.

Changes:
- repo renamed php86-windows-builds -> php-windows-builds (old URLs
  redirect automatically); description updated
- build-php-dev-latest.yaml (renamed from build-php86-dev-latest.yaml):
  - new php_ref input: build ANY php/php-src ref -- master (next dev
    version), release branches (PHP-8.6), tags (php-8.6.0RC1) or SHAs
  - new php_version=auto default: the version label is auto-detected
    from main/php_version.h of the checked-out source, so artifacts and
    releases can never be mislabeled again (the 2026-09-26 snapshot was
    labeled 8.6.0-dev while master had already moved to 8.7.0-dev)
  - the build job exports build metadata (detected version + built ref)
    as a build-meta artifact; the release job derives the tag, title,
    asset table and linked source commit from it
  - hardcoded 'PHP 8.6 features' release notes replaced with a generic
    pointer to the built ref/commit
- build-imagick.yaml:
  - new php_version input (artifact/release naming, default 8.6) and
    qa_version input (official php.net QA build for NTS binaries/devel
    packs and the script/ fallback, default 8.6.0beta2)
  - own-releases API URL updated to the new repo name
  - removed the dead workflow-level PHP_VERSION env; NTS step now uses
    QA_VERSION from the input
  - vendored source renamed vendor/imagick-php86-patched.zip ->
    vendor/imagick-patched.zip (all 5 references updated)
  - job names and debug banners made version-agnostic
- README rewritten: version-agnostic, documents php_ref/auto-detection,
  the 8.6+ Imagick patch applicability to 8.7, and a full changelog with
  an INIT 8.6 history section; stale php86-apt-builder link fixed ->
  php-apt-builder

Validation: both workflows parse as valid YAML (build, build-ts,
build-nts, release jobs intact); job/step structure unchanged apart
from the additions above.

fix(imagick): make version selection and labeling honest, overlay own…

… headers

Follow-up to the universalization commit. The first universal PHP build
(php-8.7.0-dev-2026-09-26) exposed two design gaps in build-imagick:

- the TS variant built against "latest own release" but kept a hardcoded
  php_version=8.6 label, so artifacts would have been mislabeled the
  moment the latest release stopped being an 8.6 one
- TS compiled against the official QA pack headers of whatever qa_version
  was set while linking against the own release's php8ts.lib. PHP checks
  ZEND_MODULE_API_NO at extension load (8.6 = 20260924, 8.7.0-dev =
  20260925), so a TS build for 8.7 from 8.6 headers would fail to load

Changes:
- build-imagick.yaml:
  - php_version naming-only input REMOVED; the new php_release input
    ('latest' | series like '8.6' | exact tag) selects the own-repo
    release the TS variant builds against; TS artifact names derive from
    the release actually used (job output of the selection step)
  - NTS artifact names derive from qa_version (8.6.0RC2 -> "8.6")
  - TS devel layout: own include/ is now overlaid on the official QA base
    (merge, not replace - official-only extras like script/ and win32/
    survive), so headers, php8ts.lib and the load-tested binary always
    come from the same PHP build
  - release tag/name/asset table/version line are generated from the
    assets that were actually built; mixed TS/NTS series produce an
    explicit multi-version release (imagick-vs18-x64-<date>)
  - the release job no longer runs unless every build job succeeded or
    was intentionally skipped
  - qa_version default moved to the current QA cycle: 8.6.0beta2 ->
    8.6.0RC2 (QA packs verified on windows.php.net)
  - "PHP 8.6 compatibility patch" wording -> "PHP 8.6+" everywhere
- README: fully version-agnostic rewrite (version specifics live only in
  the changelog); documents php_release / qa_version, the header-overlay
  rationale (ZEND_MODULE_API_NO) and the multi-version release case;
  changelog updated: mislabeled php-8.6.0-dev-2026-09-26 duplicate
  release removed in favor of the correctly labeled
  php-8.7.0-dev-2026-09-26
- metadata: the previous commit was rewritten to fix its committer
  identity (was the CI agent, not the repository owner); tree unchanged

Validation: both workflows parse as valid YAML; the release-metadata
bash step passes bash -n; PHP 8.6/8.7 module API numbers verified
against php/php-src (PHP-8.6 = 20260924, master = 20260925).

fix: TS imagick build uses own releases, add devel pack generation

- build-php86-dev-latest.yaml: add 'Package devel pack' step (x64 TS)
  that creates php-devel-pack with headers, .lib files, phpize.bat,
  and script/ directory from the build tree. Uploaded to release.
- build-imagick.yaml: TS job now downloads PHP binary + devel pack
  from the latest markusfoo/php86-windows-builds release instead of
  downloads.php.net/~windows/qa/ (which removes old betas).
  NTS job updated to 8.6.0beta2 from QA (no NTS in own builds).

fix: TS imagick build uses own releases, add devel pack generation

- build-php86-dev-latest.yaml: add 'Package devel pack' step (x64 TS)
  that creates php-devel-pack with headers, .lib files, phpize.bat,
  and script/ directory from the build tree. Uploaded to release.
- build-imagick.yaml: TS job now downloads PHP binary + devel pack
  from the latest markusfoo/php86-windows-builds release instead of
  downloads.php.net/~windows/qa/ (which removes old betas).
  NTS job updated to 8.6.0beta2 from QA (no NTS in own builds).

Fix: use phpsdk starter -t task mode for proper env propagation (FIXE…

…S cl.exe not found)

ROOT CAUSE IDENTIFIED:
The php/php-sdk-binary-tools starter script `phpsdk-starter.bat` ends with
`cmd /k` (interactive mode) when no TASK is provided. In GitHub Actions CI,
this means PATH and environment variables set up by vcvarsall.bat + phpsdk_setvars.bat
do NOT propagate to subsequent commands in the workflow step.

Result: cl.exe and nmake are not found even though vcvarsall reported
"Environment initialized for: 'x64'".

FIX:
Use the `-t` (task) flag of phpsdk-starter:
  call phpsdk-vs18-x64.bat -t build_php.bat

When -t is provided, phpsdk-starter.bat uses `cmd /c` (correct for CI) instead
of `cmd /k` (interactive). The task script runs INSIDE the properly configured
cmd session that has:
  - vcvarsall.bat invoked (cl.exe, nmake, link.exe in PATH)
  - phpsdk_setvars.bat invoked (php-sdk/bin in PATH)
  - All Visual C++ environment variables set

NEW WORKFLOW STRUCTURE:
1. Generate build_php.bat task script (with all buildconf/phpsdk_deps/configure/nmake commands)
2. Invoke: phpsdk-vs18-x64.bat -t build_php.bat
   (starter script handles env setup, then executes our task in that env)

Verified VS2024 install on windows-2025 runner:
  - Path: C:\Program Files\Microsoft Visual Studio\18\Enterprise
  - Visual C++: 14.51.36252.0 (VS2024 / VC18)

Author: Serhio Lee (S.K) <189266945+markusfoo@users.noreply.github.com>

Fix YAML syntax error: replace ternary ? : with && || in path express…

…ions

ROOT CAUSE:
Lines 527 and 907 used ternary operator in GitHub Actions expressions:
  path: imagick-php8.6-vs18-x64-ts${{ matrix.avx == 'avx2' ? '-AVX2' : '' }}.zip

YAML parser interprets the `:` (from ternary ?: syntax) as a mapping value
separator, causing "mapping values are not allowed here" error at column 78.
This made the entire workflow file invalid - GitHub Actions could not parse
it, so the workflow was NOT registered as active (only build-php86-dev-latest
appeared in the workflows list).

The `name:` field at line 1 was correct ("Build Imagick PHP 8.6.0beta1
VS18 x64") but since the YAML was invalid, GitHub Actions fell back to
showing the file path instead of the name in the UI.

FIX:
Replace ternary operator (? :) with logical AND/OR (&& ||):
  ${{ matrix.avx == 'avx2' ? '-AVX2' : '' }}
  →
  ${{ matrix.avx == 'avx2' && '-AVX2' || '' }}

Both expressions produce the same result, but && || does not contain
a colon character that breaks YAML parsing.

Verified: yaml.safe_load() now parses the file successfully.
The workflow will now appear in Actions tab with its proper name
"Build Imagick PHP 8.6.0beta1 VS18 x64" instead of the file path.

Author: Serhio Lee (S.K) <189266945+markusfoo@users.noreply.github.com>

Upgrade GitHub Actions to version 5 and 6