feat(db): Aurora DSQL の FOREIGN KEY 対応を取り込み、参照整合性を DB 側へ移譲する

## Problem

Aurora DSQL が FOREIGN KEY に対応しました（[Working with foreign key constraints](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-foreign-key-constraints.html)）。`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 周りだけに絞ります。

packages/db/src/dsql-compat.ts から始め、外部キーの処理を既存の CREATE INDEX → ASYNC の動作と比較してください。次に、safe-action.ts、サンプルスキーマ、AGENTS.md、packages/db/README.md、および関連する ADR を確認してください。FK SQL が必要な ADD CONSTRAINT の動作とともに保持され、DROP CONSTRAINT が許可され、重複したアプリケーションチェックが削除され、スキーマとドキュメントに変更が反映されれば完了です。

索引モデルが issue の本文から書いたものです。