Gate the finalizer's longer lock waits behind its flag

What does this MR do and why?

Context

In !266197 (merged), we gave the pending detach partition finalizer 3s and 4.5s lock waits, but didn't put them behind ci_finalize_pending_detach_partitions_daily. During a recent CI database Apdex incident, those waits made the backup of writes to CI tables worse, though they likely weren't its root cause: #631599 (comment 4147513333). Turning the flag off stops the worker's runs, but the detached partition dropper still finalizes with the longer waits. We haven't confirmed the root cause, so to be safe we're gating the waits too, so the flag turns off everything the finalizer added.

This MR

• Puts the longer lock waits behind the same flag as the worker's runs and the locks taken before FINALIZE. With the flag off, the dropper's finalize returns to the partitioning lock retry timings.
• Reads the flag once per finalizer instance, so every partition in a run sees the same value.

Feature Flag: ci_finalize_pending_detach_partitions_daily

References

• Feature flag rollout: Enable `ci_detach_archive... (#617932)
• [FF] `ci_finalize_pending_detach_partitions_dai... (#631599)
• Wait longer for locks when finalizing pending d... (!266197 - merged)

How to set up and validate locally

1. Run the finalizer spec:

   bin/rspec spec/lib/gitlab/database/partitioning/pending_detach_partition_finalizer_spec.rb

   All examples pass. retries the locks with the partitioning timing configuration fails on master, with 3000, 4500 in the recorded lock timeouts.

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.