NVDA will not tell you about mismatches.  NVDA will announce changes in indentation.  The trick is that you always know what level you're at, not that you suddenly get an auto-matcher out of it.  If the level isn't back to 0 at the end of a function, for example, then you've missed a brace.  If the level goes to 0 before the end of a function, then you've got an extra.  Doing it will eventually become first nature, which is better than second nature until you realize you can't turn it off even though your editor has decided to "help" you (not likely to be an issue for a BGT programmer).  It's in the formatting dialog.
Since I toggle it so often, nvda+n, p, f, i, space, enter.
As for your code, it's the second-to-last brace.  The syntax of do is:
do {
statements...
} while(condition);
It is worth noting that if that code was indented, it was lost when you brought it to the forum.
Since BGT is not a big deal like C++ and Python, I can't give you specific best practices for style.   But coming up with style rules is important, and I suggest following them religiously.  You may eventually wish to switch to what is known as "one true brace", that is:

do {
} while(condition);
if(condition) {
}
else {
}
while(condition) {
}

But this doesn't matter so much for languages where the community isn't large enough to have a default that spans 20 years, and your current style certainly makes checking to make sure you actually put them in easier.  The advantage to one true brace, as far as I'm concerned, is that it's simply less to arrow through.  I'm not criticizing, just providing something you might want to be aware of.  It's common in C/C++/Java.
And finally, there's always the find comments.  They don't really have an official name.  Basically it's leaving comments in that are easy to find for--for example, //todo: or, in the case of Libaudioverse, //begin public API.  This is extremely helpful in really big files.  You can split things up, but not always.  500 line files are common in the real world.  My biggest is, ironically, almost exactly 666 lines.  Anything bigger than that may be too much.  The worst I've seen is a 10000-line single-file library for playing audio that included code for 3 platforms in the same file and, ironically but not surprisingly, failed to work right.  If you're wondering about navigation, it comes down to learning find/replace and, if you can, getting an editor with find by regular expression for those times when nothing else will do.  This is one thing that C++ makes ironically easier: if you're blind, the header file makes a great table of contents for the much larger source files.