Add reproducible static PHP 8.2 build for the Lambda binary

[jerico]

Replaces the undocumented pre-8.x php in s3://hm-linter/bin with a fully-static PHP 8.2 built via static-php-cli. Static linking removes the libcrypt.so dependency and runs on any Lambda runtime OS.

• Dockerfile.php — compiles static PHP 8.2 with the extensions phpcs/WPCS/VIP need
• scripts/build-php.sh — builds ./bin/php; --upload syncs to S3

Build + publish (run per bucket, then redeploy both bots):

scripts/build-php.sh --upload
S3_BIN=s3://altis-review/bin scripts/build-php.sh --upload

Note: build:lib/deploy:check still pull libcrypt.so; harmless with a static binary, safe to drop as a follow-up once the new binary is live.

Bref's PHP layer was tested on a real Lambda (Node 22/AL2023) and failed: libreadline.so.6: cannot open shared object file. The static binary has no dynamic dependencies and is not affected.

Validated: runs on real Lambda, and lints correctly via the phpcs module using the HM-Minimum standard (v2.5.0).

Part of https://github.com/humanmade/product-dev/issues/1665

[wisyhambolu]

The approach itself looks right to me, I'm happy to approve once these are in.

[wisyhambolu]

From what I can see, the spc toolchain is currently an unpinned nightly with no integrity check.

curl -fsSL https://dl.static-php.dev/static-php-cli/spc-bin/nightly/spc-linux-x86_64

That means that two rebuilds a week apart can produce different binaries, and nothing verifies what we downloaded. This opens the door for a potential supply-chain issue.

It's not just theoretical drift in this case, that path is also the old unversioned location. Upstream's docs now point at /v3/spc-bin/nightly/, and the two currently serve different builds, so we're already getting a different toolchain than the docs describe.

dl.static-php.dev has no versioned directories or checksums to pin against, but GitHub Releases does, tagged assets with published sha256 digests. I verified 2.8.5 downloads clean and contains a single spc executable:

ARG SPC_VERSION=2.8.5
ARG SPC_SHA256=523ba4279c54c7a377156c0dd3a36adf92ee64b01e9a7f5e9e2ec084b8e458e5

RUN curl -fsSL "https://github.com/crazywhalecc/static-php-cli/releases/download/${SPC_VERSION}/spc-linux-x86_64.tar.gz" -o /tmp/spc.tar.gz \
 && echo "${SPC_SHA256}  /tmp/spc.tar.gz" | sha256sum -c - \
 && tar -xzf /tmp/spc.tar.gz -C /usr/local/bin spc \
 && chmod +x /usr/local/bin/spc \
 && rm /tmp/spc.tar.gz

I'll suggest we pin the SPC version from the GitHub release and validate via the SHA.

[wisyhambolu]

Similar pinning issue here, PHP_VERSION=8.2 is a minor-version pin

spc resolves that to whatever the current 8.2 patch release is, so rebuilds silently pick up a different PHP and we can't tell from the repo what's actually deployed. I think it is worth pinning to the full patch version (8.2.29 or whichever you validated against) so the Dockerfile records what we shipped.

[joehoyle]

I would typically agree, but given this is just for running phpcs I think it might be easier to just stick to minor, else it's going to be a lot of effort to always keep the version up to date. I am easy either way though.