Order vulnerabilities update by id to prevent ingestion deadlocks

What does this MR do and why?

Security::Ingestion::Tasks::IngestVulnerabilities::Update issues a bulk UPDATE vulnerabilities ... FROM (VALUES ...) that locks the matched rows in the order they appear in the VALUES list. The values are built from finding_maps in arbitrary order.

Advisory-driven Continuous Vulnerability Scanning and pipeline security-report ingestion run this same ingestion slice and can update the same vulnerabilities rows concurrently. Without a consistent lock order they race and deadlock on the sec primary. This was observed in production on 2026-06-16 (full root-cause analysis and log evidence in #602806).

This sorts the finding maps by vulnerability_id (the locked vulnerabilities.id) before building the update values, so all ingestion transactions acquire the row locks in the same order. It follows the existing pattern in IngestIdentifiers, which already sorts its bulk write for exactly this reason.

This is one of a series of small per-table changes tracked in &22406, complementary to the database-health backpressure and CVS-scoping discussions in #602806.

How to set up and validate locally

The change is covered by a new unit spec asserting the update values are ordered by vulnerability_id, alongside the existing behavior spec.

bundle exec rspec ee/spec/services/security/ingestion/tasks/ingest_vulnerabilities/update_spec.rb

MR acceptance checklist

• Tested (ee/spec/.../ingest_vulnerabilities/update_spec.rb, 2 examples passing)
• Follows the existing IngestIdentifiers ordering pattern

Closes #603318 (closed) Related to #602806