crawl/process の trigger に coalesce: 'queue' を導入する（durably 側機能追加が前提）

[coji]

背景

#284 (#274) で repo 追加時の初回 crawl を per-repo concurrency key (`crawl:${orgId}:${repoId}`) で trigger するようにした。これにより以下の race が残っている:

1. 定期 crawl が `crawl:${orgId}` で走行中
2. ユーザが repo 追加 → `crawl:${orgId}:${repoId}` で別 crawl が並走（key が異なるので serialize されない）
3. 後勝ちの crawl が先に `process:${orgId}` を trigger → process 起動
4. もう一方の crawl が完了して `process:${orgId}` を trigger → `coalesce: 'skip'` で drop
5. drop された側で fetch した PR は次の定期 crawl サイクルまで未処理

データロスではなく 最大 1 時間の遅延（次サイクルで自動回収）。raw データは store 済み。

なぜ今すぐ直せないか

`@coji/durably@0.15.0` の `coalesce` オプションは `'skip'` のみ。`'queue'` がない。

```ts
// node_modules/@coji/durably/dist/index-CXH4ozmK.d.ts
coalesce?: 'skip';
```

代替案として「org-wide key に戻して skip させる」も検討したが、それだと scheduled crawl 走行中の repo 追加で初回 crawl 自体が drop され #274 が実質元に戻るため不採用。

やること

1. `@coji/durably` 側に `coalesce: 'queue'` を実装
   • 同一 concurrencyKey の既存 run があれば後続 trigger を queue し、前の run 完了後に必ず実行する
2. upflow 側で適用
   • `app/services/jobs/crawl.server.ts` の `trigger-process` ステップを `coalesce: 'queue'` に変更
   • これで複数 crawl が並走しても process は順次走り、drop されない
   • 必要であれば repo-add 側の crawl trigger も org-wide key + queue に統一できる

関連

• リポジトリ追加時に初回 crawl を自動 trigger する #274 / feat: リポジトリ追加時に初回 crawl を自動 trigger (#274) #284: repo-add 時の初回 crawl 自動 trigger
• Codex review で指摘された race condition

[coji]

durably 側に feature request: coji/durably#184