#12794: fix: catch firecrawl fallback errors in web_fetch to prevent unhandled rejections

## Summary - Wraps two unprotected `fetchFirecrawlContent()` fallback calls in `runWebFetch()` with try-catch blocks so that when the firecrawl fallback also fails, the original fetch error propagates instead of crashing the gateway as an unhandled promise rejection - Updates the existing "wraps firecrawl error details" test to verify the original error surfaces when firecrawl also fails - Adds a new test verifying that HTTP errors (e.g. 502) are returned when firecrawl throws a network error on the `!res.ok` fallback path ## Problem When `web_fetch` encounters a network failure (timeout, connection refused), it tries a firecrawl fallback. If firecrawl *also* fails, the error from firecrawl escaped uncaught — either masking the original error with a confusing "Firecrawl fetch failed" message, or propagating as an unhandled promise rejection that could crash the gateway. Two code paths were affected: 1. **Lines 425-458** (initial fetch fails → firecrawl fallback): `fetchFirecrawlContent()` called without try-catch inside the catch block 2. **Lines 464-500** (`!res.ok` → firecrawl fallback): `fetchFirecrawlContent()` called without try-catch inside the error response handler The codebase already had a properly wrapped version (`tryFirecrawlFallback()` at line 580) — this fix applies the same defensive pattern to the two remaining unprotected call sites. ## Test plan - [x] Verify firecrawl fallback failure surfaces original network error (new test) - [x] Verify firecrawl fallback failure surfaces HTTP error on non-ok response (new test) - [x] All 12 web-fetch tests pass - [x] All 240 agent tool tests pass - [x] Lint clean (0 warnings, 0 errors) - [x] Build passes Closes #12773 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR wraps the two remaining unguarded `fetchFirecrawlContent()` fallback call sites in `runWebFetch()` with `try/catch` so Firecrawl failures don’t escape as unhandled promise rejections. Tests were updated to assert that when the primary fetch fails and Firecrawl also errors, the tool surfaces the original error, and a new test covers the `!res.ok` fallback path when Firecrawl throws. <h3>Confidence Score: 3/5</h3> - This PR is likely safe, but it introduces a behavior change that may reduce error diagnosability in some failure modes. - The change correctly prevents unhandled rejections by guarding Firecrawl fallback calls, and the new/updated tests reflect that. However, the new catch-all swallowing of Firecrawl errors in the network-failure path can also suppress useful Firecrawl HTTP error details (e.g., 403 responses with structured payload errors) that were previously exposed, which may not match the intended UX for fallback diagnostics. - src/agents/tools/web-fetch.ts (network-error catch + Firecrawl fallback semantics) <!-- greptile_other_comments_section --> <!-- /greptile_comment -->