fix(pilot): persist Apply — stamp applied_at on click

Issue #2 from phase-8-review-issues.md. Apply was client-side-only via
a bannerApplied flag. Refresh / chat reselect / multi-tab would drop
Verifying state back to Proposed.

- New POST /ai-sessions/{sid}/suggested-fixes/{fid}/apply stamps
  applied_at without changing status (still 'proposed'). Idempotent
  if already stamped; 409 if fix is past proposed (a terminal outcome
  was already recorded).
- Bumps state_version so resolve/escalate preview bundles reflect that
  the fix has entered verifying.
- Frontend handleApplyFix calls the endpoint and uses the returned
  applied_at directly. bannerApplied client flag is removed.

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

frontend/src/api/sessionSuggestedFixes.ts

@@ -111,6 +111,19 @@ export const sessionSuggestedFixesApi = {
     return r.data
   },
 
+  /**
+   * Stamp applied_at when the engineer clicks Apply in the ProposalBanner.
+   * Does NOT change status (fix remains 'proposed'). Status flips only on
+   * a subsequent PATCH /outcome. Idempotent if applied_at is already set.
+   * Returns 409 if the fix is no longer in 'proposed' status.
+   */
+  async applyFix(sessionId: string, fixId: string): Promise<SessionSuggestedFix> {
+    const r = await apiClient.post<SessionSuggestedFix>(
+      `/ai-sessions/${sessionId}/suggested-fixes/${fixId}/apply`,
+    )
+    return r.data
+  },
+
   /**
    * Record the outcome of applying a suggested fix. Transition rules:
    * - from `proposed` or `applied_partial`: any outcome is valid (partial is