[TASK] DPL-203: runTests.sh and workflow follow-ups

[sbuerk]

Follow-up work from the CI pipeline adoption (WVP-106) for branch 1.

Addresses DPL-203 (T1, T2, T3, T4) and DPL-213 (the explicit -i label
sweep, which is scoped to this branch only). Branch main is handled in its own
pull request and needs no label work — it is the reference state DPL-213 points
at.

What applied

Task	Verdict
T1 — MySQL-named steps run MariaDB	applied, commit 1. Four steps, no -d mysql anywhere on this branch beforehand.
T2 — renderDocumentation hardcodes -it	applied, commit 3.
T3 — --user passed without a group id	applied, commit 2.
T4a — CI_PARAMS never assigned	applied, commit 3.
T4b — DOCUMENTATION_COMMON_PARAMS unused	applied, commit 3.
DPL-213 — explicit -i	applied, commit 4. 10 steps.

Commits

[TASK] DPL-203: Run MySQL functional jobs on MySQL

The four steps named Functional MySQL 8.0 … passed -d mariadb, duplicating
the MariaDB steps directly above them under a MySQL name; there was no -d mysql
invocation on the branch at all. They run -d mysql now. The harness needed
nothing else — the mysql) arm, the mysql-func container and IMAGE_MYSQL
have always been there and were simply never reached from CI. The waitFor cap
of 60 seconds, raised in WVP-106 precisely because mysql:8.0 needs 12-13s under
docker, was confirmed still in place before making the steps real.

[TASK] DPL-203: Own the sqlite tmpfs from the host

${USERSET} passes a uid but no group, so a docker container runs as
uid=${HOST_UID} gid=0 and the --tmpfs comes up root:root with the mode of
its host mountpoint. The options move into TMPFS_MOUNT_OPTIONS, assigned per
container binary: docker adds uid/gid, rootless podman needs neither.
The existing mode=1777 is kept in both arms — do-not-touch list.
${USERSET} itself is deliberately left alone.

[TASK] DPL-203: Render docs with own parameters

Three defects sat on the one renderDocumentation run line, so they are fixed
together: the hardcoded -it on top of ${CONTAINER_INTERACTIVE} is gone (T2),
the line now uses DOCUMENTATION_COMMON_PARAMS, which was built for both
container binaries and never used (T4b), and CI_PARAMS gets its
CI_PARAMS="${CI_PARAMS:-}" assignment (T4a). Using the intended parameters also
restores --rm and, under docker, ${USERSET}. The working directory is
unchanged — neither the old line nor the parameters set one.

[TASK] DPL-213: Pin the database versions in CI

File	Step	Was	Now
testcore12 / testcore13	Functional MariaDB 10.5 mysqli	no -i, ran 10.4	-i 10.5
testcore12 / testcore13	Functional MariaDB 10.5 pdo_mysql	no -i, ran 10.4	-i 10.5
testcore12 / testcore13	Functional MySQL 8.0 mysqli	no -i, default 8.0	-i 8.0
testcore12 / testcore13	Functional MySQL 8.0 pdo_mysql	no -i, default 8.0	-i 8.0
testcore12 / testcore13	Functional PostgresSQL 10	no -i, default 10	-i 10
testcore12 / testcore13	Functional SQLite	—	unchanged, -i is rejected for -d sqlite

10 steps. Only MariaDB changes in effect (10.4 → 10.5); the others were already
running what their label claimed, but only because they happened to match the
harness default — a changed default would have moved them silently.

Deliberately not done

The matrix is not widened. main runs its pdo_mysql rows on MariaDB 10.11
and MySQL 8.4; this branch labels them 10.5 and 8.0. The decision taken is to make
this branch's labels true as they are, keeping its narrower matrix. Aligning
the two branches would add and remove matrix entries, which the WVP-106 follow-ups
explicitly forbid. This is a real drift and wants a separate decision — noted
here as follow-up, not resolved in this pull request.

Other main → 1 drift found while verifying, all out of scope here and listed
so it is not lost: runs-on: ubuntu-22.04 + actions/checkout@v4 versus
ubuntu-latest + @v6 on main; no documentation.yml and no testcore14.yml
on this branch; waitFor runs in ${IMAGE_ALPINE} rather than ${IMAGE_PHP};
the phpunit commands lack the --exclude-group not-core-${CORE_VERSION} that
main has; and renderDocumentation still hardcodes the render-guides image
literal although IMAGE_DOCS is assigned to exactly that value.

The commented-out checkRst block in both workflows is left commented — it exists
identically on main and is dormant, not a defect.

Correction to the issue text

DPL-203 T4a says CI_PARAMS is "referenced in the podman branch". It is also
expanded on the unconditional deepl-mockserver run line inside the
functional suite, so the empty expansion reaches the docker path too — 4 call
sites, not 3.

DPL-203 T4b's rationale does not fit this branch: it says renderDocumentation
uses CONTAINER_COMMON_PARAMS and therefore picks up --network, --add-host
and a stray -w. On this branch it inlined ${CONTAINER_INTERACTIVE} instead, so
the variable was dead but that particular side effect never existed here. It is
accurate for main. The conclusion — use the variable built for the job — holds
either way.

Verification

Static, plus this pull request's own CI. The functional suites were deliberately
not run locally — this is one of 20+ branches in the same sweep and each pull
request's CI exercises them.

bash -n Build/Scripts/runTests.sh                                   # clean
python3 -c "import glob,yaml;[yaml.safe_load(open(f))
            for f in glob.glob('.github/workflows/*.yml')]"         # all parse
git diff --name-only origin/1..HEAD
# -> .github/workflows/testcore12.yml, testcore13.yml, Build/Scripts/runTests.sh

Structural comparison of every workflow against origin/1 — YAML parsed on both
sides, everything except the run strings compared: identical. Exactly 10
run strings differ, all of them the intended label steps; no job, step, matrix
entry or trigger added, removed or reordered.

Every -i was fed through this branch's own handleDbmsOptions, extracted
from runTests.sh and executed, to prove the value is accepted and that the
resulting DBMS_VERSION is the one the step name claims. All 12 functional steps
pass, including the two SQLite steps confirmed to carry no -i.

Substantive property assertions, run over non-comment lines only so that an
inserted comment cannot satisfy a check (the trap the issue calls out):

• the sqlite --tmpfs uses ${TMPFS_MOUNT_OPTIONS}; the literal option string is
  gone from the code
• TMPFS_MOUNT_OPTIONS is assigned exactly twice, and both assignments still
  carry mode=1777
• the docker arm carries uid=${HOST_UID},gid=${HOST_GID}
• USERSET="--user $HOST_UID" is unchanged, one occurrence
• CI_PARAMS="${CI_PARAMS:-}" appears exactly once
• no -it remains on any code line; renderDocumentation runs with
  ${DOCUMENTATION_COMMON_PARAMS}
• occurrence counts for CONTAINER_INTERACTIVE="-it --init", the waitFor cap of
  60 and its cleanUp abort are unchanged against origin/1
• the -b docker flag count across the workflows is unchanged (36), and the
  WVP-106 workflow header comment is byte-identical in both files

Acceptance

• one pull request for this branch
• the diff touches only Build/Scripts/runTests.sh and .github/workflows/*
• no workflow job, step, matrix entry or trigger added, removed or reordered
• no -i on any -d sqlite step
• do-not-touch list intact: -b docker flags, WVP-106 workflow header
  comment, sqlite mode=1777, waitFor cap of 60 with its cleanUp; exit 1,
  CONTAINER_INTERACTIVE="-it --init"
• commit messages follow the TYPO3 rules — subject <= 52 characters, body
  wrapped at 72
• CI green