I think I know what’s going on. I think it’s because you’re querying by calendar month and aggregating by week. When you use every: 1w, Flux uses the Unix epoch as the starting point to increment and define weeks. The unix epoch started on a Thursday, so all 1w windows represent Thursday to Wednesday. aggregateWindow(), by default, uses the _stop time of the window as the new _time value of the output aggregate point. So while the queried data only contains points from last month, one or more of those points falls in a 1w window that overflows into the next month and you get a _time value from the next month.
Because you’re querying by calendar month, the length of the time range can vary and may not divide well by the every parameter. This may leave a remainder of rows that will “overflow” into a window that gets assigned a timestamp outside of the range. I’m not 100% sure.
I think the first thing you should try is to aggregate every 7d instead of one week, just to avoid the weirdness involved in with querying calendar weeks based on the Unix epoch. If that still results in this extra row, update the query time range to be a multiple of the every value. For example, range(start: -63d).
This is only a guess, but it makes sense in my head 
