No, the property_bag contains only the properties which are physically
stamped on the object.
The "real" MAPI implementation is a lot more complex. Some properties are "virtual" properties; which are either calculated out of thin air or based on other properties. They show up like any other property in something like Outlook Spy, but they don't "really
exist". Still other properties have default values; if they are stamped on the folder then that value is used, if they're not stamped then the default is used. Sometimes the default is to "check parent folder".
PR_FOLDER_TYPE is an instance of the former. mspst32.dll proper calculates the folder type based on a special bit of the node id: if this bit is set, it's a search folder, otherwise, it's a normal folder. The root folder itself (FOLDER_ROOT) is special cased.
The fact that pstsdk currently doesn't duplicate all of this logic is more or less a limitation of the SDK. This logic should map to one off helper functions on the appropriate pst layer object (folder, message, etc). property_bag is a generic lower level
object which only reads/writes physical properties; if you unwrap to that you should know what you're getting into.
Now, PR_FOLDER_TYPE is an interesting case: pstsdk is an object oriented library, MAPI (generally) is not. There are actually seperate object types for search folders and regular folders at the SDK level. So, the fact that you even have a "folder" object
implies that that PR_FOLDER_TYPE is FOLDER_GENERIC. serach_folder objects are FOLDER_SEARCH. There are seperate iterators to get at each type at every level.