Commit the completed sync unit when a v3 run is interrupted

What does this MR do and why?

V3SyncService#ingest_stream checked signal.stop? after ingesting each file, and finalize_stream commits nothing when a run is interrupted. A shard that finished ingesting got its rows written but no checkpoint, so the next run re-downloaded and re-ingested it. In the worst case a single shard's ingest eats the whole time budget and the /all bootstrap never progresses.

This MR moves the stop check above the ingest. A run now keeps every shard it finished, and the shard it stops before is never ingested.

Why it's safe:

• advance_checkpoint still only fires at a real unit boundary (new_unit?).
• Stopping mid-shard writes no checkpoint, same as before.
• The delta path (units spanning several chunks) behaves the same way.

Spec changes live in v3_sync_service_shared_examples.rb:

• Two examples stubbing stop? as always true now stub (false, true), since the reorder made them unfalsifiable.
• Added coverage that the shard or archive the run stops before never reaches the fabricator.
• Added a case for the interrupt landing before the first shard.

References

• Speed up the licenses v3 sync throttle (!254078 - merged) • Nick Ilieskou • 19.4 — the licenses v3 sync pacing MR where this came up
• Make the first (full) malware advisory sync res... (#603628 - closed) • Bala Kumar — the full-sync resume marker this interacts with
• Validate the v3 license expression sync end to ... (#627171 - closed) • Unassigned • 19.4

Screenshots or screen recordings

Backend only, no UI change.

How to set up and validate locally

Only one spec file hosts the shared examples:

bundle exec rspec ee/spec/services/package_metadata/malware_advisory_sync_service_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.