fix(init): add Sentry observability to stale-step recovery path

Previously the recovery path had no observability — there was no way
to tell from Sentry whether the fix was working in production.

- addBreadcrumb when recovery succeeds: appears in subsequent traces
  so we can confirm the recovery mechanism is actually being triggered
  and seamlessly continuing the wizard.

- captureException (warning) when recovery fails: creates a separate
  trackable event tagged wizard.stale_step_recovery=failed with the
  step ID and run ID so we can investigate edge cases where runById
  is unreachable or returns unexpected data.

The server-side CLI-SERVER-9 events (from withWorkflowErrorCapture)
continue to fire on each "step not suspended" 500, but these new
client-side events tell us the outcome of the recovery attempt.

Author: betegon

src/lib/init/wizard-runner.ts

@@ -15,6 +15,7 @@ import { randomBytes } from "node:crypto";
 
 import { MastraClient } from "@mastra/client-js";
 import {
+  addBreadcrumb,
   captureException,
   getTraceData,
   setTag,
@@ -509,10 +510,24 @@ async function resumeWithRetry(
         spin.message("Reconnecting...");
         const recovered = await tryRecoverCurrentRunState(workflow, run.runId);
         if (recovered) {
+          addBreadcrumb({
+            category: "wizard",
+            message: `stale-step recovery succeeded for ${stepId}`,
+            level: "info",
+            data: { stepId, runId: run.runId },
+          });
           return recovered;
         }
         // Recovery failed — the step is confirmed not suspended and retrying
         // it will always 500. Throw immediately instead of wasting 14s.
+        captureException(err, {
+          level: "warning",
+          tags: {
+            "wizard.stale_step_recovery": "failed",
+            "wizard.resume_step": stepId,
+          },
+          extra: { runId: run.runId },
+        });
         throw err;
       }
       if (attempt === MAX_RESUME_RETRIES) {