Fix every item's "created" date reading January 1970

Nextcloud's WebDAV server has no real per-file creation-time tracking
for most setups, so its creationdate property routinely comes back as
a placeholder Unix-epoch date ("Thu, 01 Jan 1970 00:00:00 GMT")
instead of being omitted. _parseDavDate parsed that "successfully"
into a real (if bogus) DateTime, so every item's dateCreated stuck at
the epoch instead of falling back to lastModified as it would for a
genuinely missing/unparseable value.

Add _parseDavCreationDate, which treats that placeholder the same as
an absent value, and use it at all four PROPFIND/SEARCH call sites
that read creationdate (folder listing, search, favorites, recent).

.claude/context/server.md

@@ -73,6 +73,15 @@ rather than needing a rewrite for multi-account support.
   there is no WebDAV client dependency. `_parseDavDate`/`_davPath` in this
   file exist because WebDAV responses use RFC 1123 dates and either bare
   paths or full URLs for `href`; reuse them rather than re-deriving.
+  `creationdate` specifically needs `_parseDavCreationDate`, not
+  `_parseDavDate` directly - Nextcloud has no real per-file creation-time
+  tracking for most setups, so that property routinely comes back as a
+  placeholder Unix-epoch date rather than being omitted, which
+  `_parseDavDate` alone parses "successfully" into a real (if bogus)
+  January 1970 `DateTime`. `_parseDavCreationDate` treats that placeholder
+  as absent instead, so `NextcloudItem.dateCreated` falls back to
+  `lastModified` (its constructor's default) the same as it would for a
+  missing/unparseable value.
 - **Everything else** (shares, activity, trash, favorites, quota, user info,
   file versions) goes through Nextcloud's OCS APIs (`/ocs/v2.php/...`), JSON
   in, with the `OCS-APIRequest: true` header required on every OCS call.