Use partition-aware preload for Sbom::Occurrence

What does this MR do and why?

Opts Sbom::Occurrence into the partition-aware pipeline preload framework so the possibly-affected occurrences finder avoids a cross-partition scan of p_ci_pipelines.

The with_pipeline_project_and_namespace scope now chains with_partition_aware_preload before preload(pipeline: { project: :namespace }). When the page of occurrences is loaded, the preload_associations hook resolves the :pipeline association through Gitlab::Ci::Pipeline::BulkByIdLookup (partition-pruned) and hands the pipelines to ActiveRecord's Preloader via available_records:, so:

• the pipeline lookup is pruned by partition_id instead of scanning all partitions, and
• the nested project / namespace children are still preloaded normally by the trailing super (no N+1 reintroduced).

The finder (Sbom::PossiblyAffectedOccurrencesFinder) needs no change — it chains the existing scope per batch.

Part of #601100. The framework (with_partition_aware_preload / PipelineRelationPreload) and the partition_aware_pipeline_preload feature flag are already on master, so this is a focused, independently-mergeable scope swap.

Behavior

• FF on (partition_aware_pipeline_preload): partition-pruned bulk pipeline lookup, no per-record p_ci_pipelines query.
• FF off: falls back to a vanilla bulk preload (still not N+1), by design.

How to set up and validate locally

Run the model + finder specs:

bundle exec rspec ee/spec/models/sbom/occurrence_spec.rb \
  ee/spec/finders/sbom/possibly_affected_occurrences_finder_spec.rb

The scope spec asserts: pipeline association bulk-loaded with no per-record p_ci_pipelines query, nested project/namespace still preloaded, partition pruning (partition_id in SQL) with a warm partition cache, and FF-off fallback.

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.