Regarding:
Their configuration is not using WebDAV in any way.
WebDAV is an extension to the HTTP protocol, and Laserfiche Repository Server and the client libraries that communicate with it (Repository Access, LFSO) use WebDAV functionality. It's not surprising that security tooling doing network inspection is detecting and flagging repository traffic as WebDAV, because it is.
I don't have any specific insight into what "autolockout" might be or why that call is going over port 80/http instead of 443/https. If the security tool is capturing the whole http request in question, I'd inspect it and see if there's any sort of client application identifier in the request headers that could point you in the right direction.
Edit 1:
As you've already checked all the web applications have TLS enabled for repository connections, my hunch would be that it's coming from a Repository Windows Client instance installed on the DMZ server (common for troubleshooting). The Windows Client connects to repositories over http/80 by default unless you specifically "Attach" them and check "Use TLS" (https/443) in that dialog.
Edit 2:
From looking through internal docs, "Autolockout" is a Laserfiche repository property option related to locking out a user account after too many failed login attempts. That could plausibly happen in this scenario for reasons like a Repository Windows Client session remaining logged in with cached credentials instead of being properly closed, then those creds becoming invalidated later but still try to get used. Periodic bursts of them in the logs may be suggestive of a retry loop with invalid credentials. That's also consistent with the security software flagging it a "User Authentication Brute Force Attempt".
This reinforces the importance of capturing and reviewing the HTTP requests being flagged. As they are conveniently in plaintext, you should be able to inspect them and see exactly what user account is in the login attempts.