fix: HC-DOC-TIMEOUT実機テストでn8n Data Tableノードの重複返却バグを発見・修正

returnAll:trueで取得した行が45件重複して返る不具合を確認。複数resultIdを
forループで個別処理する設計だったため実害リスクがあり、resultIdでの
ユニーク化を追加した。他ワークフローは最初の1件のみ参照または集約する
設計のため影響なしと確認。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Pleasanter/健康診断管理/docs/n8n/design-fixed-menu.md

@@ -1624,5 +1624,35 @@ SiteSettings.Columnsに`Date004`列自体が定義されていなかった**（`
 現状は自動セットされない。**今後、n8n側でProcess5実行時にDate004を明示更新する処理を追加する
 （HC-WPまたはクライアントスクリプト側）か、この既知課題自体を解決する対応が別途必要**。
 
-HC-REMINDERの4パターン（②③⑥⑦）すべて実機確認完了。HC-DOC-TIMEOUT（10分タイムアウト監視）は
+HC-REMINDERの4パターン（②③⑥⑦）すべて実機確認完了。
-未着手のまま次回対応。
+
+### HC-DOC-TIMEOUT実機テスト: n8n Data Tableノードの重複返却バグを発見・修正
+
+Status=400・PDF1件送信済み（`lastFileReceivedAt`セット済み）の状態で10分経過後にExecute
+workflowを実行したところ、実機に「診断書を受け付けました。」が届いた（結果的に1通のみ）。
+ただしn8n実行履歴を確認したところ、「対象抽出」ノードの`targets`配列に**同一行
+（513409、healthcheck_bot_stateには1行しか存在しない）が45件重複**していることが判明。
+「待機中(file)取得」ノード（`n8n-nodes-base.dataTable`、`operation:"get"`・`filters`・
+`returnAll:true`）の生出力を直接確認したところ、45個の完全に同一のアイテムが返っていた
+（Pleasanter側のn8n Public API `GET /data-tables/{id}/rows`で直接確認すると1件のみ）。
+**n8n Data Tableノードの`returnAll:true`使用時に同一行を重複して返す不具合**と判断。
+
+実際にLINEWORKSへ届いたのが1通のみだった理由: 「実行」ノードの`for (const target of
+targets)`ループが45回中1回目でStatus 400→410（Process 8実行）に遷移させ、2回目以降は
+同一resultIdへ同じProcessId=8を再実行しようとしてCurrentStatus不一致エラーとなり、
+`try/catch`の`continue`で握りつぶされたため（sendTextは`update`成功後にのみ呼ばれる
+設計だった）。**たまたま実害を免れただけ**で、異なるresultIdが複数同時に対象となる
+状況では重複送信が実際に発生しうる、根本的に修正が必要なバグだった。
+
+**修正**: 「対象抽出」ノードの`stateRows`取得直後にresultIdでユニーク化する処理を追加
+（`Set`で既出resultIdを弾く）。HC-DOC-TIMEOUTへPUT反映済み。
+
+**他ワークフローへの影響確認**: 同じData Table（`healthcheck_bot_state`）を`operation:"get"`・
+`returnAll:true`で読む箇所はHC-WAの「待機状態取得」ノードにもあるが、コード側が
+`stateRows[0]`と最初の1件のみ参照する設計のため実害なし。HC-REMINDER/HC-WPの
+`workflow_config_values`取得も`Object.fromEntries`でキー集約するため実害なし。**複数の
+異なるresultIdをforループで個別処理する設計だったHC-DOC-TIMEOUTのみ**が実害リスクを
+抱えていたため、修正はこの1箇所で十分と判断。
+
+HC-DOC-TIMEOUTは修正後、実機での再検証は未実施（次回、複数resultId状態か、n8n実行履歴で
+`targets`が正しく1件になっていることを確認すること）。inactiveへ戻した。