Oops, fix silly bug in Dyeworks Owls date parsing

Oh right, if I assume "date in the past means it's for next year", then
that means that, when the date *does pass*, we won't realize it!

e.g. if Owls says "Dyeable Thru July 15", then on July 14 we'll parse
that as July 15, 2024; but on July 16 we'll parse it as July 16, 2025,
and so we'll think it's *still* dyeable. Under this logic, it's
actually impossible for a limited Dyeworks date to *ever* be in the
past, I think!

I think 3 months is a good compromise: it gives Owls plenty of time to
update, but allows for events that could last as long as 9 months into
the future, if I'm doing my math right.

app/models/item/dyeworks.rb

@@ -70,15 +70,19 @@ class Item
 				match(DYEWORKS_LIMITED_FINAL_DATE_PATTERN)
 			return nil if match.nil?
 
-			# Parse this "<Month> <Day>" date as the *next* such date: parse it as
-			# this year at first, then add a year if it turns out to be in the past.
+			# Parse this "<Month> <Day>" date as the *next* such date, with some
+			# wiggle room for the possibility that it recently passed and Owls hasn't
+			# updated yet: parse it as this year at first, then add a year if that
+			# turns out to be more than 3 months ago. (That way, if it's currently
+			# December 2024, then events ending in Jan will be read as Jan 2025, and
+			# events ending in Nov will be read as Nov 2024.)
 			#
 			# NOTE: This could return strange results if the Owls date contains
 			# something surprising! But the heuristic nature helps with e.g.
 			# flexibility if they abbreviate months, so let's lean into `Date.parse`.
 			match => {month:, day:}
 			date = Date.parse("#{month} #{day}, #{Date.today.year}")
-			date += 1.year if date < Date.today
+			date += 1.year if date < Date.today - 3.months
 
 			date
 		end