Use numeric DAV sync tokens

[AnnoyingTechnology]

Why

SabreDAV performs numeric range comparisons and ordering on sync tokens. Davis stores the CardDAV parent and change tokens as strings, so a request spanning a decimal-width boundary can be evaluated lexically: token 10 sorts before token 9.

In practice, an incremental address-book sync starting at token 9 can return no changes after the collection advances through 10. The problem is visible on SQLite and applies to the string-backed schema on MariaDB and PostgreSQL as well.

Sync tokens are generated and incremented numerically by SabreDAV. Their database and entity types should reflect that invariant.

What changed

• store calendar, address-book, and address-book-change sync tokens as integers
• migrate SQLite, MariaDB, and PostgreSQL without deleting or rewriting DAV resources
• preserve and rebuild the compound address-book sync index when it already exists during the SQLite column replacement
• make entity accessors consistently typed as integers
• add a backend regression covering changes at tokens 9 and 10

The migration version intentionally precedes the companion index migration, but it also handles installations that apply the index PR first.

Verification

• SQLite: existing token data preserved across migration up/down/up, integer affinity verified, and the 9-to-10 range returns both changes
• MariaDB 10.11: fresh migration, exact Doctrine schema validation, migration down/up, and 60 tests / 410 assertions
• PostgreSQL 15: integer conversion, defaults, numeric range behavior, and rollback syntax exercised directly
• combined with the pending SQLite and index work: 61 tests / 414 assertions

[tchapi]

Hi

Thanks Claude for identifying this miss.

On the matter

1. There is no compound index on main, from which you branch off, no need to account for it existing or not
2. Drop the test, it's not testing anything useful in that context

The rest seem sound.

On the form

⚠️ PRs, including description and subsequent comments written by AI should be clearly labelled as such (I'm not here to read slop) (this applies to all the PRs you made)

[AnnoyingTechnology]

It's gpt5.6-sol, not slopus but point taken.

I rewrote a Dav server from scratch yesterday as it was quicker to reach my requirements, so won't be pushing for these PR. I leave it up to you to take what you deem useful to your project.