/*:#localized(key: "WhereBugsHide")
 # Count the places a bug can hide

 That single happy-path result hides a lot of ways to be unlucky. Walk the code and
 tally them:

 * **The nesting itself.**  
 Three steps, three levels of indentation, and the real logic ("bind the booklet") 
 sits farthest to the right, hardest to find. This is the **pyramid of doom**: a 
 call structure that grows sideways with every dependent step.
 * **Three separate error paths.**  
 Each `.failure` has to remember to call `completion(.failure(error))`. Miss one
 and that failure silently vanishes; the caller's completion is simply never called.
 * **The easy-to-miss completion.**  
 There is no compiler rule that says "you must call `completion` on every path."
 Add a fourth branch, forget the callback, and the page hangs forever with no error.
 * **The `self` capture.**  
 Because a handler outlives the function that started it, capturing `self` strongly 
 can keep the `PrintShop` alive longer than intended. We wrote `[weak self]`, but 
 *remembering* to, and getting it right, is manual.
 * **The main-thread hop.**  
 `bindBooklet` reports on a background queue. We added `DispatchQueue.main.async` 
 so a UI update would be safe. Forget it, and you get a bug that only misbehaves 
 *sometimes*, the worst kind to track down.

 None of these is exotic. Each is a normal Tuesday in a closure-based codebase. The
 model isn't *wrong*; it just makes correctness *your* responsibility at every
 seam.

 [Previous](@previous)  |  page 4 of 6  |  [Next: The Same Job, Rewritten](@next)
 */
