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

[sbuerk]

Follow-up work left over from the CI docker adoption (WVP-106), combined
with the database label fix, for branch main. Everything here is
pre-existing — none of it was caused by that adoption.

Addresses DPL-204 (T1, T3, T4) and DPL-214 (all 8 label edits).
The companion pull request for branch 1 carries the two tasks that
apply there.

Commits

Commit	Issue	What
[TASK] DPL-204: Run MySQL functional jobs on MySQL	DPL-204 T1	4 steps named Functional MySQL 8.0 … switched from -d mariadb to -d mysql
[TASK] DPL-204: Own the sqlite tmpfs from the host	DPL-204 T3	HOST_GID, TMPFS_MOUNT_OPTIONS per container binary, used on the sqlite --tmpfs
[TASK] DPL-204: Revive two unused harness variables	DPL-204 T4	CI_PARAMS assigned; renderDocumentation now uses DOCUMENTATION_COMMON_PARAMS
[TASK] DPL-214: Pin the database versions in CI	DPL-214	explicit -i on the 8 steps whose label names a version

Which tasks applied

• T1 — MySQL-named steps ran MariaDB: applied. 4 live steps, 2 in
  testcore13.yml and 2 in testcore14.yml. No workflow invoked
  -d mysql at all, so MySQL was never exercised. The mysql arm of
  the harness, the mysql-func container and IMAGE_MYSQL were already
  present and simply never reached, so no harness change was needed. The
  waitFor cap is still 60, as T1 requires before making these real.
• T2 — hardcoded -it in renderDocumentation: does not apply, as
  the issue already states. The only -it on this branch is the
  legitimate CONTAINER_INTERACTIVE="-it --init", which is emptied when
  CI=true. Left alone.
• T3 — --user without a gid: applied. ${USERSET} is deliberately
  untouched; the mount options moved into TMPFS_MOUNT_OPTIONS instead,
  where docker adds uid/gid and podman does not need them. The
  existing mode=1777 is kept in both, as the issue requires.
• T4 — dead variables: applied, both halves. CI_PARAMS was
  referenced but never assigned, DOCUMENTATION_COMMON_PARAMS was built
  but never read.

Label changes (DPL-214)

8 steps, 4 per workflow file, testcore13.yml and testcore14.yml:

Step	Before	After
Functional MariaDB 10.5 mysqli	-d mariadb → ran 10.4	-d mariadb -i 10.5
Functional MariaDB 10.5 pdo_mysql	-d mariadb → ran 10.4	-d mariadb -i 10.5
Functional MySQL 8.0 mysqli	-d mariadb → ran MariaDB 10.4	-d mysql -i 8.0
Functional MySQL 8.0 pdo_mysql	-d mariadb → ran MariaDB 10.4	-d mysql -i 8.0

Both values are inside what this branch's handleDbmsOptions accepts
(MariaDB 10.4–11.1, MySQL 8.0–8.4), so nothing was approximated.

Not changed: Functional PostgresSQL 10 already matches the postgres
default of 10, and Functional SQLite cannot carry an -i — the
harness rejects -i together with -d sqlite.

testcore12.yml is untouched: on main it is a dispatch-only stub with
a single dummy job that runs no tests.

Corrections to the issue text

• DPL-204 counts only the 4 MySQL steps as label defects. The 4
  Functional MariaDB 10.5 … steps also run something other than their
  name (10.4) — they are covered by DPL-214, not by T1.
• DPL-204's T4 says CI_PARAMS is referenced in the podman branch. It is
  referenced at 4 sites, and the mock-server run line is
  unconditional, so the missing assignment also affected the docker path.
• DPL-204's T4 rationale for DOCUMENTATION_COMMON_PARAMS is accurate on
  this branch: renderDocumentation really did use
  CONTAINER_COMMON_PARAMS and pick up --network, --add-host and a
  -w ${ROOT_DIR} that the later -w /project overrode. (It is not
  accurate on branch 1, which inlined ${CONTAINER_INTERACTIVE} — see
  the companion pull request.)

Verification

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

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

Structural comparison of every workflow, parsing both sides and
comparing everything except the run strings: all 5 files identical in
structure; exactly 8 run strings changed, all of them the steps listed
above. Step counts per file unchanged (testcore12 1/1, testcore13
21/21, testcore14 20/20), -b docker occurrences unchanged.

Substantive property checks, deliberately not grepping for strings that
also occur in the inserted comments:

• grep -E '^\s*TMPFS_MOUNT_OPTIONS="' → the two expected assignments
• sqlite mount uses …functional-sqlite-dbs/:${TMPFS_MOUNT_OPTIONS}, no
  literal option list left on that line
• grep -E '^CI_PARAMS="' → 1, grep -E '^HOST_GID=' → 1
• renderDocumentation run line uses ${DOCUMENTATION_COMMON_PARAMS}
• no functional step passes -i together with -d sqlite
• lines 10–34 of runTests.sh (the waitFor cap of 60 and its
  cleanUp; exit 1 abort) byte-identical to origin/main

Acceptance

• one pull request per affected branch — this one plus the branch 1
  companion
• diff touches only Build/Scripts/runTests.sh and
  .github/workflows/*
• no workflow job, step, matrix entry or trigger added, removed or
  reordered
• commit subjects [TAG] <ISSUE>: Subject ≤ 52 characters, bodies
  wrapped at 72
• do-not-touch list respected: -b docker flags, the WVP-106 workflow
  header comment, the waitFor cap of 60 and its abort,
  CONTAINER_INTERACTIVE="-it --init", and the sqlite mode=1777
• CI to confirm

[github-actions]

Documentation rendering

You can find files attached to the below linked Workflow Run URL (Logs).

Please note that files only stay for around 5 days!

Name	Link
Commit	ed79433
Logs	https://github.com/web-vision/deepl-write/actions/runs/30641831937
Documentation	https://github.com/web-vision/deepl-write/actions/runs/30641831937/artifacts/8797892754