fix(dav): compare sync token retention against an absolute cutoff

[mooons]

Summary

PruneOutdatedSyncTokensJob computes retention as a duration in seconds from syncTokensRetentionDays, but both DAV backends currently compare that value directly against created_at in pruneOutdatedSyncTokens().

created_at stores Unix timestamps, so this ends up using a relative duration as if it were an absolute timestamp. With the default 60-day retention, the generated condition is effectively created_at <= 5184000, which does not match normal rows.

Fix

Convert the duration into an absolute cutoff inside the backend methods before building the delete query:

$cutoff = max(0, time() - $retention);

and compare created_at against $cutoff.

This preserves the current method signatures and config semantics.

Root cause

The retention value is produced as an age duration in PruneOutdatedSyncTokensJob, but treated as an absolute timestamp in:

• OCA\DAV\CalDAV\CalDavBackend::pruneOutdatedSyncTokens()
• OCA\DAV\CardDAV\CardDavBackend::pruneOutdatedSyncTokens()

Impact

Without this fix, old rows in oc_calendarchanges and oc_addressbookchanges are not pruned as intended even when the background job runs.

Related: #51120

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[ChristophWurst]

I have restored the PR template. Please fill it out.

[ChristophWurst]

Changes make sense

Thanks for the contribution!