fix: let MySQL create the schema's triggers in CI

[edwh]

What's wrong

docker_run.sh runs migrate:fresh --seed as the app container starts. CI sets log_bin_trust_function_creators = 1 afterwards, in "Setup application" — by which point recreate_repair_status_triggers has already failed:

SQLSTATE[HY000]: General error: 1419 You do not have the SUPER privilege and binary
logging is enabled (SQL: CREATE TRIGGER `repair_status_str_up` ...)

migrate stops at the first failure, so every migration after that one is silently skipped.

On develop today the trigger migration happens to be the last one, so nothing is skipped and the only consequence is that CI has been running without the repair_status triggers. It's the next migration added after it that gets silently dropped — which is exactly how this surfaced, on the Nuxt branch, as an unexplained 500 from a column that should have existed.

The fix

Set it in the mounted mysql/my.cnf, so it applies from server start rather than after the app has already migrated. Verified with mysqld --validate-config. This also fixes local reseeds, which need the same SET GLOBAL by hand today.

Worth watching on this PR

Creating the triggers restores behaviour CI hasn't had, so if any test has been passing because the triggers were missing, it'll fail here. That would be worth knowing either way — a green run means the triggers were simply absent for no benefit.

The now-redundant SET GLOBAL in "Setup application" is left alone; it's harmless and still covers anyone running an older database container.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[edwh]

Verified the runtime effect rather than just that the file parses — started a stock mysql:8.0 with this my.cnf mounted:

log_bin_trust_function_creators at startup = 1
log_bin = 1
non-super trigger creation rc=0

Binary logging is on, which is the condition that triggers ERROR 1419, and a non-SUPER user creates a trigger successfully — the exact case that fails in CI today.

[edwh]

Green, which answers the thing worth watching: the full suite passes with the repair_status triggers now actually being created. Nothing had been passing because they were absent — CI was simply running without them.

So this is a straight gain: the triggers are exercised again, and the next migration added after recreate_repair_status_triggers won't be silently skipped.