Fix fractional seconds in core property timestamps

[ryanchou1994]

Core property timestamps with fractional seconds can be read as the wrong UTC time, or as None. For example, 1997-07-16T19:20:30.45+01:00 currently becomes 19:20:30 UTC instead of 18:20:30.450000 UTC. A timestamp ending in .1234Z is mistaken for a numeric timezone offset and rejected.

This separates the fractional seconds from the timezone before applying the existing offset conversion. It preserves UTC-aware results and the existing reduced-precision date formats. Fractional digits beyond Python's six-digit microsecond precision are truncated. The date setters are unchanged.

Regression tests read raw core-properties XML through all three date properties, covering positive and negative offsets, day/year boundaries, reduced-precision dates, and invalid input.

Validation on macOS CPython 3.13.13 and Linux CPython 3.13.15:

• 1,645 pytest tests and 650 behave scenarios passed on each platform.
• Ruff checks and formatting for the two changed files passed; wheel and sdist builds passed.
• Linux in-memory DOCX open/save/reopen checks passed for four fractional timestamps and all three date properties.
• Test tools use the versions recorded in the repository lockfile, including pyparsing 3.2.3. The latest pyparsing causes existing test-collection deprecation errors.

Full Pyright 1.1.401 still reports 7,577 existing diagnostics. A normalized comparison with the unchanged base shows no added or removed diagnostics; neither changed file has diagnostics. Word's GUI and Windows were not tested.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.