fix: bmad-help reads project docs and respects communication_language (#1535)

* fix: bmad-help agent reads project docs and respects communication_language

The help task fabricated tech stack information instead of reading actual
project documentation (#1460) and ignored communication_language config
(#1457). Three changes:

1. Step 2 now also extracts communication_language and project_knowledge
   from the active module's config.yaml
2. New step 3 scans project_knowledge path for documentation and uses
   discovered facts as grounding context, with anti-hallucination guard
3. Step 7 enforces {communication_language} in all output

Chose inline config resolution over workflow.yaml conversion to match
existing core task patterns (index-docs, shard-doc).

Fixes #1460
Relates to #1457

* fix: clarify config extraction wording in help task

Remove "active module" reference from step 2 — config extraction
happens during the all-modules scan, before module detection in
step 4. Changed to "each scanned module's config" to match the
existing iteration pattern.

Addresses CodeRabbit review feedback on PR #1535.

---------

Co-authored-by: Brian <bmadcode@gmail.com>

src/core/tasks/help.md

@@ -54,13 +54,15 @@ Determine what was just completed:
 
 1. **Load catalog** — Load `{project-root}/_bmad/_config/bmad-help.csv`
 
-2. **Resolve output locations** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched.
+2. **Resolve output locations and config** — Scan each folder under `_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched. Also extract `communication_language` and `project_knowledge` from each scanned module's config.
 
-3. **Detect active module** — Use MODULE DETECTION above
+3. **Ground in project knowledge** — If `project_knowledge` resolves to an existing path, read available documentation files (architecture docs, project overview, tech stack references) for grounding context. Use discovered project facts when composing any project-specific output. Never fabricate project-specific details — if documentation is unavailable, state so.
 
-4. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
+4. **Detect active module** — Use MODULE DETECTION above
 
-5. **Present recommendations** — Show next steps based on:
+5. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
+
+6. **Present recommendations** — Show next steps based on:
    - Completed workflows detected
    - Phase/sequence ordering (ROUTING RULES)
    - Artifact presence
@@ -74,9 +76,10 @@ Determine what was just completed:
    - **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
    - Brief **description**
 
-6. **Additional guidance to convey**:
+7. **Additional guidance to convey**:
+   - Present all output in `{communication_language}`
    - Run each workflow in a **fresh context window**
    - For **validation workflows**: recommend using a different high-quality LLM if available
    - For conversational requests: match the user's tone while presenting clearly
 
-7. Return to the calling process after presenting recommendations.
+8. Return to the calling process after presenting recommendations.