fix: add foreign record locking to ManyMany, OneMany, and OneOne link operations

[dkindlund]

Bug Description

saveForeignKeyForManyMany has NO record locking before modifying junction table entries. In contrast, saveForeignKeyForManyOne correctly calls lockForeignRecords before modifications (added in commit 77a8291d2).

Without locking, concurrent ManyMany link updates can:

• Create duplicate junction rows when two requests both add the same record pair
• Lose deletions when one request deletes while another reads stale state
• Cause progressive desync between JSONB cell values and junction table data

Similarly, saveForeignKeyForOneMany (non-one-way path) and saveForeignKeyForOneOne (non-ManyOne branch) modify foreign table records without locking.

Steps to Reproduce

1. Create two tables with a ManyMany link field
2. From multiple concurrent API clients, rapidly update the link field on the same record (adding/removing links)
3. Over time, the junction table accumulates rows that don't match the JSONB cell value
4. The record becomes stuck: updates crash with TypeError (foreignRecordMap mismatch), deletes fail with FK constraint violations

Expected Behavior

All link field save operations should lock affected foreign records before modifications, preventing concurrent corruption.

What This Fix Does

Adds lockForeignRecords calls to three methods that were missing them:

1. saveForeignKeyForManyMany: Locks foreign records from toDelete, toAdd, and toDeleteAndReinsert before any junction table modifications
2. saveForeignKeyForOneMany (non-one-way): Locks all affected foreign records before updating FK columns on the foreign table
3. saveForeignKeyForOneOne (non-ManyOne branch): Locks affected foreign records before modifications

Also fixes a missing await on the saveForeignKeyForManyMany delegation in saveForeignKeyForOneMany when isOneWay=true. The async call was previously fire-and-forget, meaning junction table modifications could complete after the caller assumed they were done.

Client Information

• OS: Linux (Docker container on Google Cloud Run)
• Database: PostgreSQL 17 (Google Cloud SQL)

Platform

Docker standalone (Google Cloud Run)

Additional Context

This was discovered during a production incident where a "Microsoft Windows" technology record accumulated 602 junction table rows while its JSONB cell value showed 0. The desync made the record permanently stuck — API updates crashed with TypeError and deletes failed with FK constraint violations, requiring direct database intervention to resolve.

The root cause was concurrent n8n workflow executions updating the same ManyMany link field simultaneously. The upstream fix in commit 77a8291d2 added locking to saveForeignKeyForManyOne but not to saveForeignKeyForManyMany, saveForeignKeyForOneMany, or saveForeignKeyForOneOne.