Draft: POC Splits LFKs table - one per sharding key

What does this MR do and why?

Splits LFK deleted records across 5 tables based on sharding keys, introduces a facade (DeletedRecordStore) that makes all 5 tables behave as a single unit, and updates the full pipeline (triggers, models, services, workers) to work with the new structure.

As per the discussion about making the LFKs compatible with cells, we decided to split the LFK deleted records table into 4 new tables, one per sharding key.

All 5 models share the same behavior via DeletedRecordConcern. The trigger function routes records to the appropriate table based on the sharding keys defined in each table's db/docs/*.yml dictionary entry.

Design decisions

• Facade: DeletedRecordStore is a plain Ruby class with class methods, not an ActiveRecord model. It doesn't inherit from SharedModel. This keeps it simple by delegating everything to the real models.
• Query strategy: load_batch_for_table queries all 5 models every call and merges in Ruby. This was chosen because it gives fair ordering by consume_after and the query cost (5 indexed LIMIT 500 queries) is acceptable compared to the actual cleanup work.
• Partitioning: The partitioned_by :sliding_list lambdas capture model_class = self in the included block so each model gets correctly assigned to the partition manager without duplication.
• Dependency injection (via record_store): Services receive the store as a parameter rather than hardcoding it.

Related #535508