syntaxvgm

I can provide some context to this-
It appears the golem detection is bugged where some villagers outside of the 16 block detection range detect golems. This is not the same as the bug where upgraded villagers detect them really far away, it's a new 1.21.4 world I tested in. Weirdly, it seems random which villagers are affected, as sometimes villagers closer to the golem don't see it. It also seems reloading the villagers seems to change this/cause it, but it's just a hunch I have no proof on that, I just noticed the farms seem to work better when I first open the save in then dont when I fly away and fly back.
Screenshot is from carpet ai tracker overlay, but I checked this in vanilla by checking the villager data directly.
For anyone to test themselves-

data get entity @e[type=minecraft:villager,sort=nearest,limit=1] Brain.memories."minecraft:golem_detected_recently".ttl

I don't know which version this started, perhaps I'll test them all later.

For anyone suffering this problem, I've attached a screenshot from my community facing changelog on discord. In here I describe the problem, the problems with making a solution, and how the solution we settled on works to not disable the vanilla mechanic of endermen placing blocks entirely. If you want to do that, vanilla tweaks has a nice datapack to disable them picking blocks up. 

The solution we settled on actually works really well! People still deal with (and sometimes complain) about Enderman placing blocks on their base so we maintained the mechanic, but the scoreboard in the datapack reports more than 400,000 enderman pruned and we no longer have carpets in commonly loaded areas and no endermen pockets when they dead-end. 

For anyone from Mojang that makes it to this bug, if you don't want to roll back enderman holding blocks being persistent the easy solution I'd suggest is to simply just fix it so block holding Endermen utilize and respect the PersistenceRequired tag. Not sure why they don't in the first place (there could be a reason of course), and with a problem on a smaller scale with zombies picking up mob drops and building up it was much much simpler to make a datapack to more cleanly just mark certain zombies non persistent. but gain persistence when they are holding diamond or netherite items or things of similar value. I think there are similar datapacks out in the wild that people are quite happy with and it makes it a non-issue for servers where these types of problems are actually important, but I found no such thing for endermen.  I hope the 400,000 number highlights the severity of the issue, and the datapack has only been in place less than a year on a map that started just a couple of months before the datapack. In addition, we had cleaned up the pockets by commands regularly before the datapack, so the number is not a result of the pile-up. I never actually dialed it in more aggressively either, it's quite conservative with the frequency of pruning. 

For me in the very least, the issue resolved with 1.20.1, however I did skip 1.19.4 so I'm not sure where. 
My enforce-secure-profile is still set to false from attempting to prevent this the first time, so I'll change that to true soon here and update if it causes it. 
In the very least the confusing behavior of trying to enforce the secure profiles with the setting off is gone, if it's not entirely solved. 
The issue being resolved has not been tested with a true vanilla server unlike I did for the problem, but I imagine the fix is from Mojang's end. 

(V replaying to Unplayable2)

I've found that to be an issue too, but the error is always different, related to the normal "failed to validate session" or whatever. It's been an annoying issue for some time now that I have to constantly remind players to check that the launcher actually closed when they have to revalidate every day now. But I've never seen that be the cause of this missing profile key thing, and killing from task manager never fixes it, at least in the particular case I outlined we have below ymmv. Also we've had the need the kill the launcher from task manager issue for many versions where this issue, at least for me, started in 1.19.3 and for others in comments below some version of 1.19 as that's when this system was added.

This started happening to my players en masse after upgrading to 1.19.3

As a result I have set enforce-secure-profile=false, but it makes no difference it still appears to enforce these keys regardless of this setting. 
What actually appears to be happening is anyone logged in too long to where their key expires but they are still on the server causes no one new to be able to connect. I have not been able to identify how long a person has to stay on to make this happen, as it is common for people on my server to not log out for days as the authentication making you restart everything daily or more every since the Microsoft migration basically guarantees a relog= a relaunch. I have multiple times now kicked the longest logged in player on the server and that has fixed the problem. I assume the changes allowing people to renew the keys without relogging is what is causing this as it did not happen in 1.19.2? 

Though my server is Paper, I've been able to reproduce this using a couple of accounts on a vanilla server with secure profile off. Again, don't know how long I just left it for a few days and came back. 
To anyone suffering this problem only after 1.19.3 even after turning the key enforcement off, I suggest you add an auto restart or an auto kick to your server, like 24 hours or something and adjust as needed.