Exercise 2: Same Pattern as stopScanner(), Different Stakes — Possible Solution
====================================================================

WHY IT'S THE SAME UNDERLYING PATTERN
------------------------------
In both cases, some earlier action scheduled something that's still pending (a camera stream running in Chapter 4, a pending setTimeout callback here), and a new event happening again (a new navigation away from the scan view, a new keystroke here) needs to first cancel whatever the previous instance started before proceeding - clearTimeout(searchTimeoutId) here plays exactly the same structural role as stopScanner() does in Chapter 4: cleaning up what the last run of this same logic began, before starting fresh.

WHY THE STAKES ARE DESCRIBED AS MEANINGFULLY DIFFERENT
------------------------------
If clearTimeout is forgotten here, the worst outcome is that an old, stale timer fires and triggers one extra, unnecessary search request - a small waste of a network call, with no lasting effect once that request completes. If stopScanner() is forgotten in Chapter 4, the camera stream keeps running indefinitely in the background - a real resource left open, draining battery and potentially blocking a later attempt to open the camera again, with no natural end to the problem until the page is fully closed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the shared structural pattern (cleaning up a previous run's pending action before starting a new one), and correctly explains why the actual consequence of forgetting to do so differs meaningfully between the two cases - a one-time wasted request versus an indefinitely running background resource.