This post is asking essentially the same thing. You will find some leads there.
The editor is aware of these classes because it is able to work with classes and objects that are not already loaded into memory. In order for something to be loaded in memory, you either need to load it manually or load something else that refers to it.
The approach is the latter – loading an existing reference. The simplest way to do this would be to include an array of TSubclassOf<UMyInventoryItemBase> as an editable property in a central blueprinted class like your GameMode. Any time you add a new type of item, just add a new array entry and specify that new item type. Then your loadout menu can access that same array to know which item types will be available for your player to spawn with.
If that is still too much boilerplate to your liking, I’m afraid it gets considerably more complicated. As you’ve noticed, the object iterator only includes blueprint classes once they’ve been used in the world. In order to load them, you will have to use the asset registry, the same mechanism the editor uses to be “aware” of those unloaded blueprints. As mentioned by Marc in the linked post, a good example to base yourself on is FClassHierarchy::PopulateClassHierarchy, which you will find in SClassViewer.cpp .
On top of that, this will only get you to load the missing blueprints. Once you are ready to prepare your final cooked build, you will likely have a bad surprise waiting when most of your blueprints fail to load. Like all other assets, in order for blueprints to be included in a cooked build, you need to reference them somewhere so the cooker finds them. You would do this by having the aforementioned TSubclassOf<UMyInventoryItemBase> array property. But instead of manually populating it yourself by making the array property editable, you would use your newly minted asset registry loader to populate the array.