At least in my personal experience, "dev" builds (including snapshots) "break" regularly in various ways and one has to be prepared with the appropriate recovery tools.
Looking at the commit logs can help in avoiding periods of time where there is active development going on either for the hardware/architecture of interest, or specific features. (I had some hair-pulling experiences this spring as changes were being made to netifd and hostapd.)
If you can recover easily - and given that your problem seems to reproduce reliably, the easiest way to debug this would be git bisect over the OpenWrt repo. Considering that your last known good build is pretty recent, you should be done within 5-6 rebuilds, until you know for sure which exact commit breaks it for you - knowing (and reporting) that will allow fixing it easily.
I think what @drbrains might have been hinting at is that one or both of those commits may have "broken" the build.
@slh suggesting using git bisect to locate the "first bad" commit is a good one, pone I have used myself several times. The manual for git bisect is pretty good, but basically you "start" with a known-bad commit, checkout another commit (that you already know is good), build it, test it, confirm that it's good, then mark it as "good" with git. The git system will then start checking out commits for you to test, being "smart" about it, so that you generally only have to check ~log2(number from bad to good) commits. You can find the "first bad" commit over 100 commits in about 7 tests or so.