feat: HC-WAワークフロー(LINEWORKS応答受信)を追加

LINE WORKSからの応答を受ける唯一のWebhook受信口(45ノード)をローカルJSONとして作成。
awaitInput(none/date/file)3分岐のSwitchで、既存プロセス選択・日付入力・ファイル添付の
各応答パターンをHC-SUB(Task 9)へ橋渡しする。秘密値はすべてworkflow_config_values経由の
Data Table参照。デプロイ・activateはコントローラー側で別途実施(本コミットはローカル定義のみ)。

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

NodeSrv/apps/healthcheck-survey-bot/README.md

@@ -42,3 +42,10 @@ Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`proces
   - `X-Api-Key`は`workflow_config_values`の`HEALTHCHECK_WP_API_KEY`と照合。秘密値のハードコードなし
   - 実際のcurl疎通テスト（本番508971書き込み・LINEWORKS実送信を伴う）は未実施。ユーザー確認後に実施する
   - デプロイ・活性化はサブエージェントのBashサンドボックスが実APIキー使用を一律ブロックしたためコントローラーが直接実行した（詳細: `task-10-report.md`）
+
+- ワークフロー `HC-WA: LINEWORKS応答受信`: **ローカルJSON作成のみ、n8n未デプロイ**（id未採番）
+  - ファイル: `workflows/hc-wa-lineworks-response.json`（45ノード、Webhook `healthcheck-lineworks-response` 唯一の受信口、`awaitInput`(none/date/file)3分岐のSwitch構成）
+  - 本タスクの担当範囲はワークフローJSONのローカル作成・検証までで、n8n Public APIの呼び出し（デプロイ・activate）は一切実施していない。コントローラー側での`node scripts/deploy-workflow.js workflows/hc-wa-lineworks-response.json`実行後、実際のワークフローIDをこの行に追記すること
+  - 秘密情報・SiteId等はすべて`workflow_config_values`（`bNkadTyDgDepYx2p`）から`Data Table`ノードで取得し式参照。ワークフローJSONに秘密値のハードコードなし
+  - 未検証の暫定実装あり（詳細は`task-11-report.md`）: ①Data Table `update`操作のパラメータ形状（get/insertは実機確認済みだが、updateは本タスクで初採用のため未検証）、②Switchノード(typeVersion 3)の`rules.values[].outputKey`スキーマ、③`/api/users/get`をWhere無しで呼んだ場合のレスポンス形状（配列/`.Value`/単一オブジェクトいずれにも対応する防御的実装）、④`api/items/{SiteId}/get`（ColumnFilterHash検索）のレスポンス形状、⑤LINEWORKSファイル添付のダウンロード/Pleasanterアップロードのエンドポイント（ブリーフ記載どおり実装時にPleasanter公式マニュアルapi-attachment系で要確認のプレースホルダー）
+  - 設計上の注記: HC-SUB（Task 9）が`healthcheck_bot_state`に保存する`pendingProcesses`は`{processId, label, tooltip}`のみで`ValidateInputs`を持たないため、none分岐での`classifyAwaitInput`実行時はHC-WA内で`サイト設定取得`(getsite)を再実行し、ProcessId一致でフルのProcess定義を引き直す設計にした（Task 9側のファイルは変更していない）