That's easy, it is a simple two-level classifcation issue. in your app, you need two separate drop downs, the ProductCategory is filled after the ProductType has been chosen.
One clarification: Your statement "A Product has a ProductType and can have many ProductCategory's" is contradicted by your description. A Product can have only one Product Category (Fiction, Jazz), which is based on a ProductType(Book, Music).
There is no need for surrogate keys here (there may be in other modelling requirements), they are merely redundant. For simple classifications like this, CHAR(1) or (2) is much better, user and developer friendly (when you are scanning output, you know "B" means "Book", etc), as well as being faster than any numeric key (except of course tinyint).
There is no "trick" here, it is straight Normalisation, which supports the rules you identified.
Product Classification
I do not understand the need for a "map" table.
I have provided a surrogate key for Product, but of course you need other keys, in order to implement reasonable constraints.
Questions ?
Responses to Comments
Ok, so your requirements are not clear, and it appears they are now changing. When you answer my specific questions in the comments, the model required to support your requirement will be easy. In order to assist, I have published two possibilities. Of course it is incomplete, pending your answers:
Two Possible Models
Your admin vs users "tightness" seems to be very loose.
The Product.ProductType is set by the admin. This allows the admin and users to choose Any of the valid ProductCategories for the Product for whatever use they have.
For each Product, the admin chooses the ProductType AND A SUBSET of ProductCategories (from the list of ProductCategories that are valid for the Product.ProductType). The users can then use only the ProductCategories CHOSEN by the admin for the Product, for whatever use they have.
Respond please, and then I will publish the final version.