inconsistent_error_handling

Standardize error handling pattern across the codebase medium effort

// Pick ONE pattern:
// Option A: try/catch with typed errors
try {
  await operation();
} catch (error) {
  if (error instanceof AppError) { handle(error); }
  else { throw error; }
}

// Option B: Result type
type Result<T> = { ok: true; value: T } | { ok: false; error: AppError };

Suppress a confirmed non-issue with a committed .pullguardignore entry (pullguard ignore locally, or comment /pullguard ignore <fingerprint> <reason> on the PR — the fingerprint is printed in the PR comment’s Triage section). Entries support expiresAt for time-boxed snoozes.

Security findings at major or critical severity — and any critical finding — always surface: .pullguardignore cannot hide them. The reviewed paths that keep them visible are acknowledged (reviewed, stays in reports) and, for a confirmed false positive, a reasoned false_positive entry — visible and audited, excluded only from the merge block.