Your last variant is one way to approach this. For sure you do not want a class for every category type. Unless maybe those category types come with a lot of extra business logic that defines how a product 'behaves', in which case something like Single Table Inheritance would be the better way to model this. But as you describe it I guess those are more like tags, mostly some additional description. (If there are only two or three category types and it stays that way, the number of classes won't matter that much, but if you plan more I would avoid this)
There would be one alternate option I want to mention at least for completeness and because it would save you one table and be less complex that way. This would be to model these categories simply as a hierarchy where your category types are parents and the categories are children.
Category
- Board Games
- Toy
Age Range
- 1-10
- 11-20
Cost
- Low
- Medium
- High
This is more like a 'classical' approach to this problem.
Also (especially if you have a lot of products and categories) maybe using some faceted search engine (Solr, Elastic, Sphinx...) or NOSql storage with similar abilities could make searching by several properties very easy.