PROJECT.md の Gitea リポジトリ情報を更新

PROJECT.md

@@ -48,7 +48,7 @@ status: 本番運用開始済み
 | 実行時刻 | **毎日 04:00（Asia/Tokyo）**。Dagu の `DAGU_TZ=Asia/Tokyo` を前提に `schedule: "0 4 * * *"` とする（ユーザー判断、2026-10-12） |
 | NAS 上の配置先 | `/volume1/homes/kazu634/bin/unifydrive2nas/`。`unifydrive2nas.py` と `vendor/` を置き、`tests/` は配置しない。DB は既定の `~/.local/state/unifydrive2nas/copied.sqlite3` を使う（ユーザー判断、2026-10-12） |
 | DAG の正本 | このリポジトリの `deploy/dagu/unifydrive2nas.yaml`。Dagu VM（`192.168.10.156`）の `/var/lib/dagu/dags/` へ手で配置し、Dagu 用リポジトリができたら移す（ユーザー判断、2026-10-12） |
-| リポジトリ | Gitea の非公開リポジトリ `kazu634/UnifyDrive2NAS`。リポジトリの作成はユーザーが行う（ユーザー判断、2026-10-12） |
+| リポジトリ | Gitea の非公開リポジトリ [kazu634/UnifyDrive2NAS](https://gitea.kazu634.com/kazu634/UnifyDrive2NAS)。`main` を push 済み（2026-10-12） |
 | 本番開始 | 配置した日に `--init` を 1 回だけ実行し、翌朝 04:00 から定期実行を始める（ユーザー判断、2026-10-12） |
 
 ## 要件
@@ -354,7 +354,6 @@ python3 unifydrive2nas.py --dry-run
 ## 課題
 
 - `--init` は NAS の btrfs 上で約 82 分かかった。1 ファイルごとの SQLite commit が遅く、実行中のプロセスは D 状態、処理速度は約 1.4 件/秒だった。再実行可能なため現行運用に支障はないが、1 トランザクション化または一定件数ごとの commit が改善候補。改善の実施は未着手・未決定
-- Gitea に非公開リポジトリ `kazu634/UnifyDrive2NAS` を作成する（ユーザーの作成待ち。push 未実施）
 - マウントが NAS 再起動後に自動復旧するか確認する（[[#未決事項]]）
 
 ## 経緯
@@ -367,6 +366,7 @@ python3 unifydrive2nas.py --dry-run
 - 2026-10-12: Apple 作成日時の読み取りを、version/flags の無い QuickTime 形式と FullBox 形式の両方の `meta` に対応
 - 2026-10-12: 毎日 04:00 に NAS 上のコピー処理を呼ぶ Dagu DAG と手動配置手順を作成
 - 2026-10-12: NAS へコピー処理を配置し、6,786 件を初期化。Dagu の検証・手動実行後、毎日 04:00 のスケジュールを有効化
+- 2026-10-12: Gitea の非公開リポジトリ [kazu634/UnifyDrive2NAS](https://gitea.kazu634.com/kazu634/UnifyDrive2NAS) へ `main` を push
 
 ## 確かめ方