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 周りだけに絞ります。

Start with packages/db/src/dsql-compat.ts and compare its foreign-key handling with the existing CREATE INDEX → ASYNC behavior. Then inspect safe-action.ts, the sample schema, AGENTS.md, packages/db/README.md, and the relevant ADR. Done means FK SQL is preserved with the required ADD CONSTRAINT behavior, DROP CONSTRAINT is allowed, duplicate application checks are removed, and the schema and documentation reflect the change.

Written by the indexing model from the issue text.