One brace adrift, and two loops vanished
Our source scanner blanked the start of each interpolation but left its closing brace. A brace walk stopped early, and two long loops vanished from the count.
We keep a helper that blanks comments, strings and template text out of our source before a test searches it, so a comment that mentions a function cannot be mistaken for a call to it. Every check that reads the code is told to use it instead of a home-made regular expression. This is the story of the helper being wrong.
The scan that missed the obvious
To answer whether anything in the product ran long enough to need a progress counter, we scanned the back office for every loop that waits inside itself. The scan reported eight. It missed the two on the Photos screen, which are the two most obviously long things we have: taking pictures from the library and making the till's copies, each counting out loud per row.
The helper blanked the two characters that open an interpolation and left the matching closing brace standing. Anything that searches blanked text never notices. Anything that walks it by brace depth stops at the first stray brace. Those two loops open with an interpolation, so the walk ended sixty-one characters in, before either wait, and classified a loop with two waits as having none.
The census we nearly trusted instead
The code carries three lint comments marking loops that wait on purpose, and we nearly took those as the complete set. There is no linter configured in this repository, so those comments are decorative and were never evidence of anything. The real count is eighteen across three files.
Fixed by blanking the closing brace when it returns the text to template mode, at no cost, because the helper writes a space for every blanked character and every offset still lines up. The scan then found ten, the two missing being exactly the pair the walk had truncated past. A tool everyone is told to trust earns a test of its own.