Also note on the "data type" as chosen: you can't change it anymore, but I would have done this:

1. first the year, since if you order, you can order on year - but you can't order on month as the year is further in the value only (in your usage)
2. use month numbers (01, 02. 03, …) instead of names, as also here you can order on numbers, not on names (as it happens to be that month sequence inside a year is not alphebetical). But also : a named month is also language dependent, and numbers are not.
3. Optionally, whet you can do is this (and exmple for the current month) 2025-07-[july2025] You can order this AND you can see the name in a human readable manner, because the ordering happens to the left of the value (as is typical for words, even if we filled them with numbers), and when the sorting is actually completed (at the month number), you can enter any letter/number/character after that

Maybe even better would have been two columns, one with year only, one with month only, and make that a combined Primary Key and also the base of partitions. Maybe you could partition per year, and inside sub-partition per year and month. And then you can still sub-partition more.

Without knowing all the columns in detail it's best to use the actual same filter in the queries as those used in the partitions … and no functions ! Exact string matches … For that I'm not sure if using LIKE is even a good option. Given there are only 12 months in a year, and you know the values of these 12 months I would test if all goes faster if you name the months literally. OK, coding becomes much more complex, but … partitioning is about performance. If you're in that corner, speed is your objective.