At a very quick scan of the code:

• When the 'mark as bot' option is checked, it appears that SpecialMassGlobalBlock temporarily gives the bot right to the user making the global blocks (SpecialMassGlobalBlock.php#L482-L485).
• However, from what I can see so far, the code responsible for placing each of the global blocks doesn't do anything that would result in the RecentChange class being told to mark each specific log entry as a bot action. IIUC (judging by RecentChange.php#L996-L997 in mediawiki/core), actions by an account holding the bot right aren't automatically marked as bot actions in RecentChanges just by virtue of the bot right being held. (edit: struck, see below)
• It appears that this might be able to be fixed by adding a new parameter to the GlobalBlockManager::block function (link) to represent whether a global block should be recorded as a bot action, calling ManualLogEntry::setForceBotFlag (link) when that parameter is true, and setting the parameter to true in the call from SpecialMassGlobalBlock::performGlobalBlockChanges (link) when the 'mark as bot' option is checked.
  • If I understand correctly, this would also mean that the user would no longer need to be temporarily granted the bot right, as RecentChange doesn't appear to check for the presence of this right when the option to force the 'bot' flag has been set (RecentChange.php#L993-L994).
• When the 'also block locally' option is selected in addition to the 'mark as bot' option, if the intended behaviour is for any local (i.e. meta-wiki) blocks to also be marked as bot actions in RecentChanges, a change to core MediaWiki-Blocks code may also be needed -- as, from what I can immediately see, the core BlockUser class (link) doesn't seem to currently provide an option to force the 'bot' flag for a block log entry it creates.

Someone from Trust and Safety Product Team should probably check my working here though :)

Edit 2025-04-07: struck something that I was embarrassingly wrong about. In its call to $wgRequest->getBool(), RecentChange.php#L997 provides true as the default value for when the bot parameter isn't defined -- therefore, the code responsible for placing each of the global blocks doesn't need to "do anything that would result in the RecentChange class being told to mark each specific log entry as a bot action" - simply assigning the bot userright should have been enough.
I think that when I read that line of code, I must have inadvertently skimmed over the fact that it set a default value of true; and I therefore thought that the bot parameter would have needed to be manually given a truthy value in order for the bot flag to be applied by RecentChange::newLogEntry(). My apologies to anyone I may have inadvertently mislead with my incorrect analysis!

That's my understanding too. I did quickly look through how to fix this task when I added the sprint tag. Thanks for detailing this.

One thing I'd say is it seems the bot flag appears to work for local blocks, because we have a test for this: https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalBlocking/+/7eec35cd53e844937fc87a2b2def5d397b8021be/tests/phpunit/Integration/Special/SpecialMassGlobalBlockTest.php#440

In T387659#10614918, @Dreamy_Jazz wrote:

One thing I'd say is it seems the bot flag appears to work for local blocks, because we have a test for this: https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalBlocking/+/7eec35cd53e844937fc87a2b2def5d397b8021be/tests/phpunit/Integration/Special/SpecialMassGlobalBlockTest.php#440

Unfortunately, that doesn't fully seem to be the case. I tested with both the 'block locally' and 'mark as bot entries' options enabled, but the local block and global block still appear in the recent changes.

An attempt to search for the log item on Quarry shows that rc_bot is 0, despite selecting the option to mark them as bot entries: https://quarry.wmcloud.org/query/91542.

In T387659#10614918, @Dreamy_Jazz wrote:

That's my understanding too. I did quickly look through how to fix this task when I added the sprint tag. Thanks for detailing this.

No problem - apologies if my comment was just repeating things that people were already aware of!

In T387659#10615664, @XXBlackburnXx wrote:

In T387659#10614918, @Dreamy_Jazz wrote:

One thing I'd say is it seems the bot flag appears to work for local blocks, because we have a test for this: https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalBlocking/+/7eec35cd53e844937fc87a2b2def5d397b8021be/tests/phpunit/Integration/Special/SpecialMassGlobalBlockTest.php#440

Unfortunately, that doesn't fully seem to be the case. I tested with both the 'block locally' and 'mark as bot entries' options enabled, but the local block and global block still appear in the recent changes.

This matches what I've noticed -- testing locally & on Patch Demo, the bot flag doesn't seem to be being applied for local blocks made using Special:MassGlobalBlock; so potentially that test might be passing when it shouldn't be.

Change #1133227 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/core@master] ManualLogEntry: Check RecentChanges bot flag before POSTSEND

https://gerrit.wikimedia.org/r/1133227

Change #1133227 merged by jenkins-bot:

[mediawiki/core@master] ManualLogEntry: Check RecentChanges bot flag before POSTSEND

https://gerrit.wikimedia.org/r/1133227

Confirming that I can no longer reproduce the issue. Thank you very much!

QA is completed, and the new code has been implemented and is functioning as expected (The Block actions have been marked as bot entries and hidden from the default Recent Changes view, as per the selected option).