Fix secret detection scans for scheduled SEP

What does this MR do and why?

Fix secret detection scans for scheduled scan execution policies by properly passing pipeline context to ScanPipelineService.

As described in #570139, the first scheduled scan execution policy doesn't trigger historic scan as expected. This was caused by ScanPipelineService being called twice during pipeline creation:

1. From CreatePipelineService - with correct SECRET_DETECTION_HISTORIC_SCAN variable
2. From ee/lib/ee/gitlab/ci/variables/builder/scan_execution_policies.rb - without pipeline context, causing the variable to be incorrectly set to false

This MR fixes the issue by:

• Moving secret detection variable logic from CreatePipelineService to ScanPipelineService
• Passing branch and pipeline_source parameters to ScanPipelineService to enable proper context-aware variable calculation
• Ensuring ScanPipelineService can determine whether to use SECRET_DETECTION_HISTORIC_SCAN or SECRET_DETECTION_LOG_OPTIONS based on previous pipeline execution history
• Updating the CI variables builder to pass pipeline context when initializing ScanPipelineService

The fix ensures that:

• First scheduled SEP runs trigger historic scans (SECRET_DETECTION_HISTORIC_SCAN=true)
• Subsequent runs use incremental scanning with commit ranges (SECRET_DETECTION_LOG_OPTIONS)
• User-provided SECRET_DETECTION_HISTORIC_SCAN variables are respected and not overridden

References

Closes #570139

How to set up and validate locally

1. Create a scheduled scan execution policy with secret detection
2. Trigger the first scheduled pipeline
3. Verify that SECRET_DETECTION_HISTORIC_SCAN=true is set in the secret detection job
4. Trigger a second scheduled pipeline
5. Verify that SECRET_DETECTION_LOG_OPTIONS is set with the commit range instead

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.