The question is who’s writing the code. A core part of a senior engineer’s job is helping to train and mentor junior engineers; it’s not unusual for an entire project to be designed and led by a senior engineer and implemented by more junior engineers. Design reviews don’t result in commits, deep dives on technical implementations don’t result in commits, negotiating an architecture change between groups don’t result in commits. A large amount of the actual heavy-lifting value-add of an actually senior engineer is not in the code they’re writing.

This. Spending a productive, rewarding half a day pair programming with a receptive junior engineer who isn't sure how to approach a complex task nets them 1+ commits and you 0 commits. Spending half a day chasing after a "loose cannon" engineer who hastily committed bad code nets them 3 commits (the original bad commit, a rollback commit, and the fixed commit) and you 0 commits.

How do the individual stats look at the end of the month/quarter/Musk Layoff Review Period when these kinds of days are relatively common?

All that, in theory, would be tracked. The senior engineer would be able to point to the PRs/MRs with all the helpful comments that led to the code improvements. It wouldn't be hard to show calendar invites or whatever for pair programming sessions, which could be corroborated by asking the junior as well.

It does, however, bring up the point that one should always be mindful of what their output looks like and how easy it is to prove. I'm sure everyone has worked with a 'meeting commando', who loves to discuss edge cases and bikeshed instead of shipping code. Maybe they've carved out a nice niche doing so, and have convinced others in the company of their (dubious) value, but it shouldn't be surprising when the company is sold/acquired/RIFd that someone else might expect someone with an engineering title to have more tangible contributions to point to.