fix(deletions): Fix Monitor deletion timeouts

[yuvmen]

changed MonitorCheckIn to be deleted using BulkModelDeletionTask.
It used to need individual deletions to clean up attachments manually but attachments were removed from this model and it can now safely use Bulk deletion to speed things up.

should fix:
SENTRY-41GE

[sentry]

Bug: MonitorCheckIn deletion via BulkModelDeletionTask will fail due to unhandled MonitorIncident foreign key references.
_{Severity: CRITICAL | Confidence: 0.95}

🔍 Detailed Analysis

When MonitorCheckIn records are deleted using BulkModelDeletionTask, and MonitorIncident records still reference them via starting_checkin or resolving_checkin foreign keys, the database will attempt to enforce foreign key constraints. Since these foreign keys lack database-level CASCADE delete configuration, this will lead to database constraint violation errors and unexpected deletion failures, preventing the bulk delete operation from completing successfully. The PR author overlooked the existing MonitorIncident foreign key relationships to MonitorCheckIn.

💡 Suggested Fix

Create a MonitorIncidentDeletionTask to handle MonitorIncident deletion before MonitorCheckIn, or configure database-level CASCADE delete on the foreign keys, or revert to ModelDeletionTask for MonitorCheckIn to process child relations.

🤖 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/deletions/defaults/monitor.py#L15-L17

Potential issue: When `MonitorCheckIn` records are deleted using
`BulkModelDeletionTask`, and `MonitorIncident` records still reference them via
`starting_checkin` or `resolving_checkin` foreign keys, the database will attempt to
enforce foreign key constraints. Since these foreign keys lack database-level `CASCADE`
delete configuration, this will lead to database constraint violation errors and
unexpected deletion failures, preventing the bulk delete operation from completing
successfully. The PR author overlooked the existing `MonitorIncident` foreign key
relationships to `MonitorCheckIn`.

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

_{Reference_id: 2749526}

[yuvmen]

I was conflicted about this, we have foreign keys with CASCADE set up on these. I believe this means they should be getting deleted automatically when the bulk task deletes them at the DB level, cursor agrees, I believe this is probably wrong but I am not sure.

[armenzg]

You can always deploy and see if there are more optimizations.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #103495      +/-   ##
===========================================
+ Coverage   72.69%    80.62%   +7.92%     
===========================================
  Files        9241      9246       +5     
  Lines      394715    394936     +221     
  Branches    25169     25169              
===========================================
+ Hits       286956    318399   +31443     
+ Misses     107331     76109   -31222     
  Partials      428       428