I think you have two problems closely related to each other. 

 - Static classes contains logically unrelated functions
 - Names of static classes do not provide helpful information about
 meaning/context of the contained functions.

Problems can be refactored by combining only logically related methods in one static class and move other in their own static class. 
Based on your context/domain or problem you should decide by yourself/or with team which logic you will use for separating methods in related static classes.

Below is detailed explanation of your concerns and possible solutions: 

_mostly unrelated to each other_ - **problem** 
Refactor it by combining related methods under one static class and move unrelated methods to the own static class.

_without explicit state persisted across invocations_ - not problem, 
static classes doesn't required to have any state. If static class have a state, state become global. In case if you writing tests for your application global state become difficult to maintain in the tests.

_small_ - not problem. 
Methods should be small

_each consumed by a variety of unrelated types_ - not problem, you have created a general method which can be re-used in many not related places.

_A static class is being used solely as a namespace_ - not problem, this is a style how static methods are used. Unless you using static method as extensions
 
_The static class identifier is basically meaningless_ - **problem**. 
It is meaningless, because developers putting unrelated methods in it. Put unrelated methods to the own static classes and give specific and understandable name.

_When a new GLUM gets added, either (a) this "bag" class gets touched (SRP sadness)_ - not problem if you follow idea that only logically related method should be in one static class. 
`SRP` not violated here, because principle should be applied for classes or for methods. Single responsibility of static classes is contain different methods for one general "idea". Idea can be feature or conversion, or iterations(LINQ), or data normalization, or validation ...

_or less frequently (b) a new "bag" class gets created (more bags)_ - not problem. 
classes/static classes/functions - are our(developers) tools, which we use for designing software. Does your team have some limits for using classes? What is maximum limits for "more bags"? Programming is all about context, if for solution in your particular context you end up with 200 static classes which understandably named, logically placed in namespaces/folders with logical hierarchy - it is not a problem. 

_The meta-naming is inescapably awful, non-standard, and usually internally inconsistent, whether it's Helpers, Utilities, or whatever_ - **problem** 
Give better names for classes and methods, which describe expected behaviour. 
Keep only related methods in one class, which provide help in better naming.


From automating testing point of view - if static functions contain complicated logic which used by different consumers/classes - you probably should introduce an abstraction(interface) where it's implementation will contain those methods. 
Abstraction give you possibility to not test this logic multiple times through it's consumers. In consumer's unit tests you will be able to mock up logic and concentrate testing on the actual logic.