test(schema): re-home the five FKs #2239 de-declared under the NO ACTION block

[jakebromberg]

Fixes red main.

What broke

#2246 removed five false onDelete declarations from schema.ts (#2239) but left tests/unit/database/schema.fk-cascades.test.ts asserting they were still present. The suite fails on main at ddfa9445 with 5 failures.

Why CI said green, and why that generalizes

The unit-tests job runs Jest in affected-tests mode — its log ends Ran all test suites related to changed files. This spec reads the schema as text:

const schemaSource = fs.readFileSync(path.resolve(__dirname, "../../../shared/database/src/schema.ts"), "utf-8");

There is no import, so no edge in Jest's dependency graph, so editing schema.ts never marks this spec as related and it was never selected. #2246's run executed 244 suites / 4917 tests; the full suite is 462 / 8050. Any test that guards a file it does not import sits in the same blind spot — filed separately as #2249, since fixing the selection mechanism is a bigger decision than fixing this spec.

The fix re-homes rather than deletes

The spec already had a should NOT have onDelete (intentional NO ACTION) block, which is precisely where these five belong now. Moving them there keeps the test's protective value, pointed the other way: it pins #2239's decision and fails if someone re-adds a cascade to schema.ts without also moving the deployed constraint. Deleting the assertions would have left that decision unguarded at the unit level, which is how it drifted in the first place.

A comment at the block records why the five are NO ACTION and what to do if one genuinely needs to cascade later (add it in the PR that introduces the delete path, pair it with a migration, update the case here).

artist_library_crossreference.library_id deliberately stays under cascade — #2239 did not touch it, and migration 0147 (BS#2112) repaired that constraint to CASCADE in the database, so the declaration is accurate.

Also adds an expectNoOnDelete helper mirroring the existing expectOnDelete; the NO ACTION block was repeating the same four lines per case.

Verification

• This spec: 19/19, unchanged total (was 14 passed / 5 failed).
• Full unit suite: 462 suites / 8050 tests, 0 failures — confirming this was the only breakage affected-mode was hiding.

Refs #2239, #2246. Related: #2249.