tepples is correct - there are (at least?) 7 CPU cycles of delay before the first instruction is executed (to fetch the reset address, etc.). This is 21 PPU cycles, but I ended up going with ~28? cycles purely because this is the value that gave the closest result compared to hardware results for the read2004.nes test, but there is no science behind the 28 cycles (odds are that it is somewhat incorrect).
The trace log's "CYC" value for the PPU is shown after the first byte of the instruction has been loaded, so it ends up writing 30 (which is the value of the last PPU cycle that was executed - e.g a total of 28+3 cycles have been executed by the time the CPU finishes processing the first instruction's first byte)
Trying it out in "Visual NES" and loading a NROM game into it, it looks like the first instruction starts executing around cycle 25-26. So Mesen is probably delaying the CPU's startup compared to the PPU a bit too much.
If you're just working on your CPU's code, though, you can just ignore the PPU cycles for now, the PPU should have no impact on any of those tests.
//The CPU takes some cycles before starting its execution after a reset/power up
for(int i = 0; i < (model == NesModel::NTSC ? 28 : 30); i++) {
_console->GetPpu()->Exec();
}