Exercise 3: Why an Unimplemented ZXing Fallback Passes Testing and Still Ships a Bug — Possible Solution
====================================================================

WHY IT PASSES A DEVELOPER'S OWN TESTING
------------------------------
A developer testing locally is very likely using a Chromium-based browser (Chrome, Edge) on a desktop or an Android device, where "BarcodeDetector" in window is true. In that environment, the native detector branch runs every time, and the unimplemented fallback branch simply never executes - there's nothing to notice, because the code path that's broken never gets exercised during that testing.

WHICH USERS WOULD ACTUALLY BE AFFECTED
------------------------------
Anyone using Safari on iOS - where BarcodeDetector is not supported - would hit the else branch, which does nothing at all. For those users, the scan screen would render normally but never detect a barcode, with no error message and no visible sign anything is wrong. Given how large a share of real-world mobile users are on iPhones, this isn't a small edge case.

WHY CHROME-BASED TESTING WOULD NEVER CATCH IT
------------------------------
The bug only exists inside the untested branch. Testing exclusively in Chrome/Edge/Android never causes that branch to run at all, so no amount of testing in that environment - however thorough otherwise - would ever surface the problem. Only testing on an actual Safari/iOS device would exercise the broken path and reveal the silent failure.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the bug lives entirely inside a code path Chrome-based testing never triggers, correctly identifies Safari/iOS users specifically as the affected group, and correctly explains why no amount of same-browser testing could ever catch it - only testing the actual untested branch would.