Eh, go lookig for trouble and you find it...
Yes I can verify I have these too, mostly from Androids in my case.
My working hypothesis is the controllers mistakenly snooping an address out of a initial DHCPRequest, ARP, or IP packet from a stale home wifi or mobile carrier connection. All the strange addresses are either 10.x, assigned to carriers, or the firewalled-but-public DoD ranges that big carriers squat on. There's too much chunking for these to be just randmly distributed.
The clients actually get normal on-network addresses and those are the ones they are using, it is just a stray user-table entry. Having servers in 10.0.0.x in general sets you up for more collisions with home networks. It may be worth developing a plan to gradually move servers to a less obvious subnet of 10.
I took debug logs, compared them to user table entries, and found that there was DHCP activity by these clients at the same time these user entries are created. However the logs for the traffic only ever has the correct address that the client got from our external DHCP server, no sign of the bad adresses there.
(Also had a stray client manage to accidentally linger on the control plane long enough to pull an AP IP address, despite denyall initial/preauth role. That's a different issue. I'll have to assign a default vlan to that profile someday to avoid the race condition there.)