fix(sql): validate referential actions, and repair the publishing workflow

[JustGodWork]

The two items left open after the audit follow-up. Based on #4.

Referential actions were concatenated into the DDL unvalidated

onDelete and onUpdate were upper-cased and appended verbatim to the FOREIGN KEY clause:

belongsTo("users", { key = "user_id", onDelete = "cascade, add x int" })
-> FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE, ADD X INT

This was the last unvalidated path left in the SQL builder after the operator and sort-direction whitelists, and it matters as soon as a schema is built from configuration rather than written by hand. Actions now go through a whitelist (CASCADE, RESTRICT, NO ACTION, SET NULL, SET DEFAULT) and accept the usual spellings: set null, set_null, SET NULL.

The publishing workflow fired twice per merge and could not push

Three pre-existing defects in build.yml:

Merging a PR into master triggered the workflow twice, once as a push to master and once as pull_request/closed with merged == true. The concurrency group did not collapse them because github.ref differs between the two events (refs/heads/master versus refs/pull/N/merge), so both jobs rebuilt and both raced to push the same commit.

The pull_request run could not have pushed anyway: on that event actions/checkout leaves a detached HEAD, and the bare git push fails with You are not currently on a branch as soon as dist/ has actually changed, which is the normal case.

The comment presented github.actor != 'github-actions[bot]' as the primary guard against an infinite build loop. It never fired: actions/checkout persists SUBMODULES_PAT, so the bot's push is attributed to the PAT owner, never to the bot. The only thing breaking the loop was the [skip ci] in the commit message, described in the comment as a mere "second safety net". Anyone editing that message would have re-armed the loop while believing the actor check protected them.

Fixed by keeping a single trigger (the push to master already covers a merge), making the concurrency group a constant, pushing with an explicit refspec, and dropping the check that did nothing. The comment now describes the guard that actually works.

Note

On a push to master, test.yml and build.yml both build and run the suites, so the work is duplicated. It is harmless, and it does mean the bundle is verified twice before publication, but test.yml could drop master from its push trigger if you would rather save the minutes.

Suite: 364 passing, 357 before this branch.