Gate pipeline archival behavior behind ci_pipeline_archival_setting

What does this MR do and why?

Introduces the ci_pipeline_archival_setting ops feature flag and uses it to gate the existing pipeline archival behavior (archive_builds_in_seconds admin setting) per project. This sets up the controlled rollout of CI/CD pipeline archival on GitLab.com described in epic gitlab-org#19547.

The flag is default_enabled: true so self-managed and Dedicated are unaffected on upgrade. On GitLab.com it will be flipped off via chatops before the deploy, then gradually re-enabled per project / group through the rollout issue.

Three call sites are gated:

• Ci::Pipeline#archived? wraps the Gitlab::CurrentSettings.archive_builds_older_than read so the cutoff is treated as nil when the flag is off for the project. The AccessLogger call still fires on every invocation so we keep observability into access patterns during rollout.
• Ci::CreateCommitStatusService#first_matching_pipeline only applies the .not_archived scope (the only production caller of that scope) when the flag is enabled for the project.
• Ci::Partitions::ArchiveService#archive_builds_older_than is gated with the :instance actor — partition archival runs in a background worker without per-project context, so we use an instance-wide kill switch there. A short comment explains the mixed-actor approach.

The mixed actor types (project vs :instance) for one flag is safe because the per-project and partition-archival code paths never share a request context.

Issue

Closes #600846 (closed)

Screenshots or screen recordings

N/A — no UI changes.

How to set up and validate locally

1. Set the admin setting archive_builds_in_seconds to something short (e.g. 3600).
2. Create a pipeline older than the cutoff.
3. With the flag enabled (default) for the project, retrying the pipeline is blocked.
4. Disable the flag for the project: Feature.disable(:ci_pipeline_archival_setting, project).
5. Retrying the pipeline succeeds; Ci::Pipeline::AccessLogger still logs the access attempt.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.