Typically ModSecurity only adds an audit log for requests that it blocks. This is because those requests are usually the ones you want more info on, to understand why it was blocked. Additionally you would not want your audit log to log every request as they are large entries and the log would get quite large on even a moderately used web server.
In this case the request was not blocked by ModSecurity and passed back the 302 request so I would not expect the request to be in the audit log in typically ModSecurity setups.
As discussed in the comments your SecAuditEngine config setting was set to RelevantOnly which is the typical setting following above logic. So the other POST entries you saw must be for POST requests that were ultimately blocked by ModSecurity. Change the SecAuditEngine value to On to log all transactions and you should see what you want. As I say this will log a lot of data so you probably only want it on for a short time. Alternatively you could write a rule to only turn on the AuditEngine for these transactions to reduce
SecRule REQUEST_URI “@beginswith /wp-login.php” \
“phase:2,id:1234,nolog,ctl:auditEngine=On,pass”
It should also be noted that this will log all POST params including the password (in pwd param). This is considered pretty bad form (even system administrators should not know passwords as they should be stored as one way hashes), so you should sanitise this argument to prevent it being logged into the audit log by setting this rule first:
SecRule ARGS_NAMES "pwd" "phase:5,id:1233,nolog,pass,sanitiseMatched,t:lowercase"
