docs: README記述をToken取得ボディ修正後の実装に合わせて更新

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

@@ -45,7 +45,7 @@ Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`proces
   - 未検証・要判断の暫定実装あり（Task 12以降で要確認）:
     ①484184(`LINEWORKS_BOT_MASTER_SITE_ID`)からのBotId解決ロジック（実データ構造未調査のため`SiteSettings.BotIds`または`Processes[].BotId`を仮定し、無ければ例外を投げる。「JWTクレーム組み立て」ノードに実装）
     ②`/api/users/get`のレスポンス形状（配列/単一オブジェクト両対応の防御的実装、「Pleasanter照会・選択肢組み立て」ノードに実装）
-    ③LINEWORKS token/message呼び出しを`this.helpers.httpRequest`で行う際のform-urlencodedボディの正しい渡し方（`URLSearchParams`文字列＋`Content-Type`ヘッダー明示という実装にしたが、n8n本体でこの組み合わせが期待通り動くかは実機未検証。ダメな場合は`n8n-nodes-base.httpRequest`ノードの`contentType: "form-urlencoded"`に戻す変更で対応）
+    ③LINEWORKSトークン取得は`URLSearchParams`インスタンスをそのまま`body`に渡す形に修正済み（`.toString()`化や`json:true`併用はn8nのform-urlencoded自動処理と衝突する懸念があったため回避）。レスポンスは文字列/オブジェクトいずれでも`access_token`を読めるよう防御的にパースしている。ただしn8n本体での実機動作は本タスクでは未検証
     ④`Data Table`Insertノードの`columns.mappingMode`/`value`/`schema`の形状（旧19ノード版から流用。旧版はデプロイ実績があるためスキーマ自体は疑わしくないが、実書き込みでの動作は本タスクでは未再検証）
   - テスト実行（Step 4相当）は本タスクでは未実施。次回、捨てレコードでの疎通確認とユーザー確認が必要