Problem
Aurora DSQL が FOREIGN KEY に対応しました（Working with foreign key constraints）。ADD CONSTRAINT に NOT VALID が必要な点を除けば、ほぼ Postgres と同じように書けます。
一方 kit は FK 非対応前提のままで、packages/db/src/dsql-compat.ts が生成 SQL から REFERENCES / FOREIGN KEY を無言で削除します。schema.ts に .references() を書いてもエラーにならず、FK なしのテーブルができます。DROP CONSTRAINT も "Table recreation required." で弾かれますが、こちらも今は使えます。
FK 非対応時代は「無言で削除」が妥当でしたが、現在の仕様であればDB側でも参照整合性を設けるのが好ましそうです。
Proposed solution
dsql-compat.ts: FK をそのまま通し、ADD CONSTRAINT には NOT VALID を自動付与（CREATE INDEX → ASYNC と同じ方針）。DROP CONSTRAINT も許可する- サンプルスキーマ:
TodoItem.userId → User.id に FK を追加（参照アクションは既定の NO ACTION）
- アプリ層:
safe-action.ts の users 行の存在チェックを削除。FK があれば重複するため
AGENTS.md / packages/db/README.md と ADR を更新
ALTER TABLE 許可リスト全体の見直しは #220 のスコープなので、ここでは FK 周りだけに絞ります。
Problem
Aurora DSQL が FOREIGN KEY に対応しました（Working with foreign key constraints）。
ADD CONSTRAINTにNOT VALIDが必要な点を除けば、ほぼ Postgres と同じように書けます。一方 kit は FK 非対応前提のままで、
packages/db/src/dsql-compat.tsが生成 SQL からREFERENCES/FOREIGN KEYを無言で削除します。schema.ts に.references()を書いてもエラーにならず、FK なしのテーブルができます。DROP CONSTRAINTも "Table recreation required." で弾かれますが、こちらも今は使えます。FK 非対応時代は「無言で削除」が妥当でしたが、現在の仕様であればDB側でも参照整合性を設けるのが好ましそうです。
Proposed solution
dsql-compat.ts: FK をそのまま通し、ADD CONSTRAINTにはNOT VALIDを自動付与（CREATE INDEX→ASYNCと同じ方針）。DROP CONSTRAINTも許可するTodoItem.userId→User.idに FK を追加（参照アクションは既定の NO ACTION）safe-action.tsの users 行の存在チェックを削除。FK があれば重複するためAGENTS.md/packages/db/README.mdと ADR を更新ALTER TABLE許可リスト全体の見直しは #220 のスコープなので、ここでは FK 周りだけに絞ります。