Refactor/optimize the `/compareSummary` API

Opening this per #12071.

Repeating/rephrasing from https://github.com/IQSS/dataverse/issues/12071#issuecomment-3745372326:

The performance of /api/datasets/.../versions/compareSummary seems unreasonable/unacceptable on datasets with many files.
Testing on qa w/ one of our control datasets, w/ ~1.5 K files, /api/datasets/:persistentId/versions/compareSummary?persistentId=doi:10.7910/DVN/29236 takes ~17 sec. as of 6.9. The actual differences between versions (3 total) are minimal (~1Kb of json output). Most of this time must be from instantiating, then crawling through the lists of filemetadatas/datafiles for each version.
My educated guess is that it should be easy to replace this with native queries and achieve the same result much faster.

We already have a named native query in FileMetadata.java for finding files changed between versions that @qqmyers created for the purposes of optimizing file indexing. It can be used as a model/to build on top of.

Start at the /api/datasets/.../versions/compareSummary endpoint and inspect FileMetadata.java, especially the existing named native query for finding files changed between versions. Compare the current behavior and output with the query-based approach using a dataset with many files. Done means preserving the compareSummary result while substantially reducing its response time.