Exercise 2: Why Two Calls to stopScanner(), and What a Missing Third Would Cause — Possible Solution
====================================================================

WHY TWO CALLS EXIST
------------------------------
There are exactly two distinct ways a user can currently leave the scan view: successfully scanning a barcode (handled inside the onDetected callback) or clicking the cancel button (handled by its own click listener). Since neither path automatically triggers any cleanup on its own, each one needs its own explicit stopScanner() call to actually stop the camera.

WHAT WOULD HAPPEN WITH A THIRD, UNHANDLED WAY TO LEAVE
------------------------------
If a new way to leave the scan view were added later - for example, a global navigation menu allowing the user to jump to a different section of the app while still on the scan screen - and that new path didn't also call stopScanner(), the camera stream would keep running in the background indefinitely after the user left that view. Nothing would visibly signal the problem; the browser's own camera-in-use indicator might stay lit, and the camera would continue consuming resources with no view left on screen actually using it.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies the two current exit paths as the reason for the two existing calls, and correctly describes the concrete, silent consequence of adding a third exit path without a matching stopScanner() call - an orphaned, still-running camera stream with no visible error to flag the mistake.