feat(suggested-fix): add applied_pending status for deferred verification

Engineer applies a fix but can't verify yet (waiting on client power-cycle,
AD replication, async sync). Today the verifying banner forces a synchronous
verdict (worked / didn't / partial) — anything else means leaving the banner
stale or guessing wrong. This adds a fourth outcome that parks the fix in a
non-terminal "Awaiting verification" state with a reason ("waiting on what?")
and exposes it on the chat-anchored banner so the engineer doesn't lose track.

Backend
- New non-terminal status `applied_pending` parallel to `applied_partial`.
- New `pending_reason` column (nullable Text) — the "what are you waiting on?"
  prose, mirrors `partial_notes`. Required when outcome=applied_pending.
- Outcome endpoint allows pending in/out transitions; pending stamps
  applied_at but NOT verified_at (it's parked, not verified).
- Resolution-note + escalation-package prompts handle the new status:
  resolution note frames the fix as provisional; escalation package surfaces
  pending verification as the leading hypothesis with reference to what's
  being waited on.
- Migration: add column + extend status CHECK constraint.

Frontend
- New `BannerMode = 'pending'` + `PendingBanner` component (info-tone,
  parallel to PartialBanner) with worked / didn't / update-reason actions.
- VerifyingBanner overflow menu adds "Waiting to verify…".
- Nudge banner's "Still checking" button now actually records pending with
  a reason, instead of just silencing for the session.
- AssistantChatPage banner-mode derivation maps applied_pending → 'pending'.

Tests: 4 new integration tests covering pending notes requirement, reason
storage + applied_at/verified_at semantics, pending→success transition,
and pending_reason update on re-PATCH.

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

backend/app/services/resolution_note_generator.py

@@ -83,6 +83,10 @@ 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.
+- applied_pending: Note that the fix was applied and verification is pending. \
+If pending_reason is provided, include it (e.g. "awaiting client power-cycle"). \
+Frame the resolution as provisional — the fix is in place but not yet \
+confirmed. Do not write closure language.
 - 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: \
@@ -322,6 +326,8 @@ class ResolutionNoteGeneratorService:
                 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.pending_reason:
+                lines.append(f"Pending reason: {active_fix.pending_reason}")
             if active_fix.failure_reason:
                 lines.append(f"Failure reason: {active_fix.failure_reason}")