feat(issues): add merge task killswitch

[cvxluo]

For inc-2274

[sentry]

Bug: Calling end_merge when the merge killswitch is activated can leave groups in a PENDING_MERGE state while prematurely notifying Snuba that the merge is complete.
_{Severity: HIGH}

Suggested Fix

When the killswitch is activated, the end_merge function should not be called with the original, complete list of previous_group_ids. Instead, the system should either revert the PENDING_MERGE status for any unprocessed groups or call end_merge only with the IDs of groups that were successfully merged before the interruption.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/sentry/tasks/merge.py#L82-L84

Potential issue: The new killswitch logic can cause a state inconsistency between the
primary database and Snuba. If the killswitch is activated during a recursive merge
operation, `end_merge` is called immediately. This function is invoked with the original
`eventstream_state`, which includes all group IDs from the start of the merge. However,
if only a subset of groups has been processed, the remaining groups will be left in a
`PENDING_MERGE` state in the database. Snuba receives the `end_merge` signal for all
groups, leading it to believe the entire operation is finished. This discrepancy causes
Snuba's event routing to be incorrect for the unprocessed groups.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[yuvmen]

I think this is fine, them staying in pending_merge is ok they will have to just be cleaned up manually when after a killswitch which is acceptable