Thanks again. As I said, it is quite likely that the overall behavior is consistent with the workings of the Adam procedure; I am still getting up to speed on certain details. I’m certainly not alarmed, just a bit curious. One trigger is that, from endless experience inspecting things in a debugger, when I see odd FP values, for example the dreaded xxx.e-308 for double precision, this is often the result of either uninitialized values, where initialization is expected, or somebody pushing an integer into what is supposed to be a FP location.
So similar “near-zero but not quite zero” Float32 values do trigger a bit of suspicion. (But not alarm; that  is reserved for inf or nan values :-).) The apparent absence of true zero values added to that, I guess. Because of the large overhead in valgrind runs, I’ve only done limited checks on optimization, and these did not raise any flags.
Given that the optimization seems to advance properly, I will just proceed with the assumption that these values were on their way to zero, but just didn’t quite make it. No problem marking this as “solved”.