Make module-stage LLM handling resilient and report warnings

docs/release-checklist.md

@@ -40,6 +40,7 @@ Use this checklist before cutting a pre-1.0 or 1.0 release candidate.
 - Verify structured response schemas are attached via `response_format.type=json_schema`.
 - Verify diagnostics metadata includes structured schema `id/version/name/sha256`.
 - Verify provider output is still locally decoded/validated before use.
+- Verify malformed module-stage structured payloads degrade to warnings/rejections instead of failing the run.
 
 ## Report and diagnostics schema checks
 
@@ -67,6 +68,7 @@ Use this checklist before cutting a pre-1.0 or 1.0 release candidate.
 - Verify prompt metadata appears in LLM request metadata diagnostics:
   - `prompt_id`, `prompt_version`, `prompt_source`, `embedded_path`, `sha256`.
 - Verify stable validator keys appear in report decisions/rejections.
+- Verify module warning records appear in reports for malformed proposal-generation payloads and malformed validator batches.
 - Verify built-in validator chains resolve and execute for default and explicit module runs.
 
 ## Utilization diagnostics checks
@@ -96,6 +98,8 @@ Use this checklist before cutting a pre-1.0 or 1.0 release candidate.
 ## Failure and cancellation checks
 
 - Verify controlled failure paths retain diagnostics and produce best-effort failure reports.
+- Verify malformed proposal-generation payloads keep exit code `0`, keep stderr empty on success, and record warnings in reports/diagnostics.
+- Verify malformed validator payloads reject only the affected batch and do not fail the module.
 - Verify timeout/cancellation paths exit nonzero, do not hang, and retain failure diagnostics when initialized.
 
 ## Release fixture/idempotence checks