fix(backend): log the real bootstrap failure cause server-side

Session bootstrap swallowed configure/retrieval errors and surfaced only the
generic BOOTSTRAP_FAILURE_MESSAGE, so an operator could not tell why a session
"didn't start" — e.g. `tht search pack` failing because the DWH/vector host is
unresolvable behind a dropped VPN. Log the underlying error to the backend
console; the client-facing message stays generic.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

backend/src/routes/sessions.ts

@@ -142,7 +142,11 @@ export function sessionRoutes(
         info(id, "Starting model");
         if (d.mgr.get(id) !== rt) return;
         start();
-      } catch {
+      } catch (error) {
+        // The client only ever sees the generic BOOTSTRAP_FAILURE_MESSAGE; log the real
+        // cause server-side so failures (e.g. an unreachable DWH/vector host behind a
+        // dropped VPN) are diagnosable from the backend console instead of silent.
+        console.error(`[pi:${id}] bootstrap failed:`, error instanceof Error ? error.message : error);
         void withSessionLifecycle(id, async () => {
           // A bootstrap continuation can settle after Close/Delete or after a replacement was
           // installed. Claim only the runtime identity that actually failed; holding the same