Use a Gregorian calendar for --due-date components

[sakamossan]

EKReminder.dueDateComponents only accepts DateComponents whose calendar is Gregorian or nil.
NaturalLanguage.swift builds them with Calendar.current, which follows the calendar the user picked in
System Settings > General > Language & Region. With a non-Gregorian calendar (e.g. Japanese or Buddhist),
every --due-date aborts:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
    reason: 'Calendar must be nil or Gregorian'
        2   EventKit   -[EKReminder(Shared) setDueDateComponents:] + 948
        3   reminders  RemindersLibrary.Reminders.addReminder(string:notes:toListNamed:dueDateComponents:priority:outputFormat:)

It happens for every --due-date spelling (2026-09-30, 2026-09-30 10:00, tomorrow at 10am).
edit --due-date from #108 goes through the same parser, so it is affected as well.

To reproduce without changing the system-wide setting, set the locale for reminders only:

$ defaults write reminders AppleLocale -string "ja_JP@calendar=japanese"
$ reminders add <list> "test" --due-date tomorrow
$ defaults delete reminders AppleLocale

Change

• Use Calendar(identifier: .gregorian) when converting the detected Date into DateComponents.
  Parsing is unchanged: NSDataDetector resolves the string into an absolute Date before the calendar is
  used, and the time zone is still passed explicitly.
• Build the test expectations with a Gregorian calendar too, so the tests pass regardless of the calendar
  setting of the machine running them, and add a test that the parsed components use a Gregorian calendar.

Testing

On macOS 26.6.2 (Xcode, Swift 6.2.1) with the Japanese calendar:

• reminders add <list> "test" --due-date tomorrow and --due-date "2026-09-30 10:00" create the reminder
  instead of crashing (2.5.1 from Homebrew crashes with the same setting)
• swift test on main: 7 of the existing tests fail with this patch applied to the source only, because the
  expectations are built with a Japanese DateComponents. With the test change, those pass and so does the new test.
• testTodayNoon, testTonight and testTomorrowAtTime still fail on this machine, but they fail on main as
  well, independent of the calendar: dateComponents(in:from:) on macOS 26 also fills in dayOfYear, which the
  expectations don't include. I left that out of this PR; CI on macos-14 is not affected.