Backfill file sizes per extension version instead of per file resource

[netomi]

What

Scopes the FileResourceSizeMigration backfill (#1777) by extension version rather than by individual file resource: an extension version's handful of resources (download, README, CHANGELOG, icon, sha256 checksum, ...) are now backfilled together in one job, instead of one job (and one migration_item row) per resource — for a registry with millions of resources, that's a lot fewer jobs for JobRunr to carry for the same amount of work.

How

• FileResourceSizeJobRequestHandler now looks up the ExtensionVersion and loops over all its file resources via migrations.getFileResources(extVersion), backfilling each one still missing a size. A resource whose object is missing from storage (FileNotFoundInStorageException, from Tolerate missing storage objects in the file-size backfill #2094) no longer aborts the whole job — its siblings are still processed.
• MigrationService.getFileResources(ExtensionVersion) added, delegating to RepositoryService.findFiles — the same accessor FixMissingFilesJobRequestHandler already uses.
• V1_73__File_Resource_Size.sql's seeding updated to insert one migration_item per extension version that still has an unsized resource, rather than one per file resource. Edited in place rather than layered as a new migration, since nothing has shipped with the original seeding yet. Also fixes the seed insert to use migration_item_seq (MigrationItem's actual sequence since V1_40) instead of the unrelated hibernate_sequence it was using before.

Testing

• FileResourceSizeJobRequestHandlerTest rewritten for the per-extension-version shape: no-op when the extension version is gone, backfills every unsized resource while skipping already-sized ones, and one resource's missing object doesn't block backfilling the rest of that version's resources.
• Full unitTests suite passes (949 tests).
• Verified against a real Postgres instance (ExtensionVersionJooqRepositoryTest, which boots the full Spring context) that the updated V1_73 migration still applies cleanly.

🤖 Generated with Claude Code