fix(docker): move action base image from debian 10 to debian 12 (KTLO-212)

[dparuship]

Summary

Debian 10 "buster" is EOL and its suites have been removed from deb.debian.org. The RUN apt-get update && apt-get install -y git layer now 404s and exits 100, so this action's image no longer builds at all:

E: The repository 'http://deb.debian.org/debian buster Release' does not have a Release file.
ERROR: failed to build: failed to solve: process "/bin/sh -c apt-get update && apt-get install -y git" did not complete successfully: exit code: 100

Consuming workflows fail at the Build uship/action-deploy-to-wpengine@main step — before Checkout — so nothing is deployed and nothing is partially deployed.

This bumps the base image to debian:12-slim (bookworm). One line, no other changes.

Blast radius — please read before merging

Eight repos reference this action as @main, across dev, sandbox and prod deploys (~20 workflows): uship-wordpress-theme-new, ushipabout-, ushipblogs-, ushipbusiness-, ushipconnect-, ushipguidessd-, ushiplearnsubd-, ushipportals-wordpress-theme.

Because they float on @main, this change takes effect everywhere the moment it merges. All of those deploys are broken today, so the change can only improve on the status quo — but it is not a scoped rollout, and the next push to any theme repo's main will exercise it against production WP Engine.

Bullseye was considered and rejected: its LTS window closes this month, which would reintroduce the identical failure shortly.

The one real behavioural risk, and why it's cleared

Debian 12 moves openssh-client from 7.9 to 9.2. OpenSSH 8.8+ disables SHA-1 ssh-rsa signatures by default, and entrypoint.sh does ssh-keyscan -t rsa git.wpengine.com with RSA deploy keys — so this was the plausible way the bump could break deploys at runtime rather than build time.

Verified it does not:

• git.wpengine.com runs OpenSSH 8.9 and advertises rsa-sha2-512,rsa-sha2-256 in its host key algorithms, and rsa-sha2-256,rsa-sha2-512 in server-sig-algs. The existing RSA keys authenticate via SHA-2 signatures.
• Reproduced the entrypoint's known_hosts flow inside the built image. Host key verification with StrictHostKeyChecking=yes succeeds, and the connection reaches publickey auth (Permission denied (publickey) — expected, no key was mounted).

Test plan

• docker build succeeds on debian:12-slim
• git (2.39.5), bash (5.2) and openssh-client (9.2) all still present from apt-get install -y git — no package list change needed
• ssh-keyscan -t rsa git.wpengine.com returns the host key inside the image
• Host key verifies under OpenSSH 9.2 with StrictHostKeyChecking=yes; connection reaches publickey auth
• End-to-end deploy against a non-production WP Engine environment (deploy-dev.yml in one of the theme repos) before relying on it for a prod push

Found while diagnosing a red Deploy to Prod run in ushipblogs-wordpress-theme (uShip/ushipblogs-wordpress-theme#25). That PR was unrelated to the failure — the action image has been unbuildable independently of it.