fix(pilot): outcome-aware Resolve/Escalate previews

Issue #1 from phase-8-review-issues.md. Cache invalidation alone isn't
enough — previews were also omitting outcome fields from the LLM bundle,
so a fresh regenerate still couldn't distinguish proposed / failed /
partial / success.

- PATCH /outcome now bumps ai_sessions.state_version (matches
  record_decision's existing pattern).
- Resolution-note + escalation-package bundles now include status,
  applied_at, verified_at, partial_notes, failure_reason on the active fix.
- Generator prompts prescribe outcome-aware phrasing (closure language
  for success; what-we've-tried + next-steps for failed/partial).
- New end-to-end test asserts the regenerated preview reflects the
  recorded outcome, not just that the cache key changed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/app/services/resolution_note_generator.py

@@ -69,11 +69,24 @@ say "Root cause not definitively isolated." and explain what is suspected based
 on facts.>
 
 ## Resolution
-<one short paragraph describing the resolution applied. If a script ran during \
-the session, mention it (e.g. "Cleared cached credentials via the \
-clear-outlook-credentials script."). If no resolution has been performed yet, \
-write "Resolution not yet applied — fix proposed: <fix title>." Pull verbatim \
-script names and template references when available.>
+<The content of this section depends on the outcome recorded for the active \
+suggested fix, as given in the input bundle under "fix.status":>
+
+- applied_success: Write in past tense using closure language. State that the \
+fix was applied and verified as working. If verified_at is provided, you may \
+reference it as the time resolution was confirmed. Example phrasing: \
+"Applied <fix title>; confirmed working."
+- applied_failed: Acknowledge that the proposed fix did not resolve the issue \
+and was discarded. If failure_reason is provided, include it. Then describe \
+the actual resolution path taken (derived from facts and scripts run). This \
+state means the engineer resolved the issue another way; the note should cover \
+that actual resolution, not just the failed attempt.
+- applied_partial: Note that the fix was partially applied. If partial_notes \
+are provided, include them. Then describe the final resolution path taken.
+- dismissed: Treat the fix as considered and set aside. Do not center the note \
+on it. Describe the resolution based on what was actually confirmed and done.
+- proposed (no outcome yet): Write "Resolution not yet applied — fix proposed: \
+<fix title>." Pull verbatim script names and template references when available.
 
 Strict rules:
 - Use ONLY the facts and state I provide. Never invent specifics that are not \
@@ -302,6 +315,15 @@ class ResolutionNoteGeneratorService:
             lines.append(f"Description: {active_fix.description}")
             if active_fix.user_decision:
                 lines.append(f"Engineer decision: {active_fix.user_decision}")
+            lines.append(f"Outcome status: {active_fix.status}")
+            if active_fix.applied_at:
+                lines.append(f"Applied at: {active_fix.applied_at.isoformat()}")
+            if active_fix.verified_at:
+                lines.append(f"Verified at: {active_fix.verified_at.isoformat()}")
+            if active_fix.partial_notes:
+                lines.append(f"Partial notes: {active_fix.partial_notes}")
+            if active_fix.failure_reason:
+                lines.append(f"Failure reason: {active_fix.failure_reason}")
 
         lines.append("")
         lines.append("# Scripts run during the session (passwords redacted)")