The restore was counting up to 198 (files?) and 3.6 GB. It seemed odd that it exceeded 198 and reached 199 and continued to run for quite a while with 100% completion and 0s remaining.
Upon completion it stated 166 files were restored. I am assuming that is perhaps because there were 32 (or 33?) existing files in the target directory?
While this is very annoying, I think many programs that do try to report progress will bump the progress number as it finishes its write() of the file, but then there are 4-5-6-7 layers of caching done by the OS, the file system, the device driver code, the scsi/sata controller and bus, the device itself, so while your program may have sent the last bytes of the last restored object, when you call for fsync() or something like that to try to ask all the above mentioned layers to actually flush their buffers, it may have lots and lots of unwritten megabytes of data left in all layers that need to get pushed down until the sync is actually done and those files can be considered written such that a power outage will not make them disappear again.
Not certain this is what happens here, but I think this is why many installers are often stuck at 99 or 100, waiting for that final flush.
If that is on a *nix system you could try to attach some debugging to the process and see what it is waiting for. I wouldn’t know how to do that on Windows or even macOS, though.
On Linux strace would show you what is going on and what system calls the process is still making, or if it just waits for some other process to finish.