fix(cli): surface fatal [STARTUP] boot diagnostics without --log (#13314) (#13779)

Merged in the 2026-09-16 sweep of the maintainer's own open PRs, at the owner's explicit instruction. No push was made to the PR branch: the merge took the head as the owning session left it (verified OPEN, non-draft and MERGEABLE against the release tip immediately before merging).

bin/cli/utils/ensureAndroidCacheDir.mjs

@@ -105,6 +105,27 @@ export function isFatalInstrumentationHookFailure(text) {
   return /Unsupported platform:\s*android/i.test(text);
 }
 
+/**
+ * Detect any fatal boot-time diagnostic guarded by the `[STARTUP] Fatal:`
+ * prefix (`src/instrumentation-node.ts::ensureDbReadyForBoot()`,
+ * `src/instrumentation.ts::register()`, and any future guard using the same
+ * marker). #13314: in the default `omniroute serve` mode (no `--log`),
+ * `ServerSupervisor` only buffers stdout/stderr and flushes it to the real
+ * console on exit/crash/readiness-timeout — so if the HTTP listener still
+ * comes up after a fatal boot diagnostic was already printed (e.g. the
+ * better-sqlite3 / node:sqlite driver cascade failing hard), the operator
+ * sees "OmniRoute is running!" with zero visible diagnostic anywhere, and
+ * every route 500s. This generalizes the #10028 Android/Termux carve-out to
+ * every `[STARTUP] Fatal:` guard, not just that one platform-specific string.
+ *
+ * @param {string} text
+ * @returns {boolean}
+ */
+export function isFatalStartupDiagnostic(text) {
+  if (!text) return false;
+  return /^\[STARTUP\] Fatal:/m.test(text);
+}
+
 /**
  * Operator-facing hint when that instrumentation failure shows up in child
  * output — defense in depth if prep was skipped or a future Next.js probe