Repeating to-do templates report a fake deadline of 1953-01-01 #153

written by Claude Opus 5.5; reviewed by @mikez

To Reproduce

With the test database (tests/main.sqlite) on main:

>>> things.get("N1PJHsbjct4mb1bhcs7aHa")["deadline"]  # "Repeating To-Do" template
'1953-01-01'

The to-do has no deadline in Things.app.

Cause

Two things combine:

1. Repeating to-do templates store 262213760 in TMTask.deadline. That is
   the Things date 4001-01-01, which seems to mean "no deadline" on templates.
   In the comment by @duanefields in Repeatable to-dos: include next in things.upcoming(). #122, every template in their database had
   this value.
2. convert_thingsdate_sql_expression_to_isodate masks the year with 11 bits
   (y_mask = 0b111111111110000000000000000), so years above 2047 wrap:
   4001 is shown as 1953. This also affects a regular to-do in the test
   database: "To-Do in Upcoming" (7F4vqUNiTvGKaCUfv5pqYG) has startDate
   4001-01-01 and is returned with start_date '1953-01-01'.

Fixing only (2) would make the template's deadline read '4001-01-01', which
is still not a real deadline.

Expected behavior

• A template with no deadline returns no deadline key, like other to-dos
  without a deadline.
• Things dates with years above 2047 decode to the correct year, or the
  reason they can't is documented.

Context

Until now this was only reachable through things.get(uuid), since list
queries excluded templates. PR #152 makes templates appear in
things.upcoming() and things.tasks(is_repeating_template=True), so the
fake deadline shows up there too.

@duanefields also found in #122 that the real deadline of a repeating to-do is
relative to each occurrence and can be read from the recurrence rule:
plistlib.loads(rt1_recurrenceRule)["ts"] is the negated number of days
after the occurrence. That could be a follow-up; this issue is only about not
reporting a fake date.