Reduce example count in processor

What does this MR do and why?

The shared example 'with different scan type' in ee/spec/lib/gitlab/ci/config/security_orchestration_policies/processor_spec.rb ran its whole suite (15 examples) once per pipeline source in %w[api pipeline merge_request_event schedule]. It is included three times (DAST, secret detection, SAST), so that loop produced 180 examples. Now only 'collects the injected jobs and metadata in the pipeline context' stays inside the per-source loop. The other 14 examples (stage insertion, job naming, reserved .pre/.post stages, invalid stages) run once per scan type under the spec's default source of 'pipeline'.

The source does not affect those 14 examples, for these reasons:

• Gitlab::Ci::Config::SecurityOrchestrationPolicies::Processor never reads the pipeline source. It builds ScanPipelineService.new(context) with no pipeline_source.
• In Gitlab::Ci::Pipeline::ScanExecutionPolicies::PipelineContext, the source only gates applicability through return false unless Enums::Ci::Pipeline.ci_sources.key?(source). All four looped sources are ci_sources, and none is in Enums::Ci::Pipeline.dangling_sources.
• Security::ScanExecutionPolicy#applicable_for_pipeline_source? filters policies with rule_pipeline_sources.blank? || rule_pipeline_sources.include?(pipeline_source.to_s). The spec's policies have no pipeline_sources in their rules, so this is true for all four sources.
• The one source-sensitive branch is PipelineContext#job_options, through scheduled_source?. It is true only for :security_orchestration_policy or :ondemand_dast_scan. That is why the job options example stays looped per source.

No coverage was removed. Every assertion still runs for every scan type, and the per-source job options check still runs for all four sources.

Spec Run Time Optimization Results

Before optimization:

• 194 examples
• Run time: 0m 38s (37.92s)

After optimization:

• 68 examples
• Run time: 0m 20s (20.10s; a second run gave 20.21s)

Improvement:

• Example count reduced by: 64.9% (194 to 68)
• Run time reduced by: 0m 18s (17.82s)

Verified with:

bundle exec rspec ee/spec/lib/gitlab/ci/config/security_orchestration_policies/processor_spec.rb --dry-run  # example count
bundle exec rspec ee/spec/lib/gitlab/ci/config/security_orchestration_policies/processor_spec.rb            # full run

Both runs measured in the same local checkout for a fair comparison (same warm Rails boot, same DB/Gitaly state), swapping only this file's content between the pre- and post-optimization version.

bundle exec rubocop ee/spec/lib/gitlab/ci/config/security_orchestration_policies/processor_spec.rb reports no offenses.

Estimated CI Cost Savings

Using the same methodology as this earlier spec optimization MR: 17.82s saved per pipeline × $0.03/minute (large runners: 3x cost factor on $10/1,000 base minutes).

Scenario	Pipelines/month	Time saved/month	Savings/year
Pessimistic	15,000	74.2h	$1,603.80
Moderate	30,000	148.5h	$3,207.60
Optimistic	50,000	247.5h	$5,346.00

How to set up and validate locally

1. Checkout this branch.
2. Run bundle exec rspec ee/spec/lib/gitlab/ci/config/security_orchestration_policies/processor_spec.rb.
3. Confirm 68 examples, 0 failures.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.