Add logging to database sticking operations

Summary

Add logging to database sticking operations (.stick and .bulk_stick) to help debug cases where users may read stale data from replicas despite proper sticking mechanisms being in place.

Problem

During investigation of database consistency issues, we've identified cases where users appear to read stale database values even when sticking should ensure they read from up-to-date replicas. We need visibility into sticking operations to understand timing and potential conflicts between concurrent operations.

Proposed Solution

Log whenever .stick or .bulk_stick methods are called, including:

• Stick type (e.g., :user, :project)
• ID or IDs being stuck
• Current LSN (Log Sequence Number)

For .bulk_stick operations, always log the count of IDs. When there are more than 20 IDs, log an empty list for the IDs field to avoid overwhelming the logging infrastructure with very long log messages in this frequently-called code path. Put all logging behind a feature flag log_database_sticking_operations.

The methods to modify are located in lib/gitlab/database/load_balancing/sticking.rb#L47-59.

Acceptance Criteria

• Add logging to both stick and bulk_stick methods
• Include stick type (this is confusingly called namespace in the arguments list to stick), ID(s), and LSN in structured log output
• Always log count of IDs for bulk operations
• Log empty list for IDs when bulk operation has >20 IDs
• Implement feature flag (default: disabled)