fix: clean up related records when deleting entities

[anonymoususer72041]

This PR adds missing cleanup for related records when deleting candidates, companies, contacts and job orders.

Previously, deleting these entities could leave orphaned references behind in related tables such as activities, calendar events, saved list entries, attachments, extra field values, candidate tags, candidate/job order history, company departments and questionnaire history. The affected delete flows now remove directly owned related records and reset remaining references according to the existing schema semantics.

A migration has been added to clean up orphaned references that may already have accumulated in existing installations.

Regression coverage has been added for candidate, company, contact and job order deletion cleanup.

[anonymoususer72041]

Note: Follow-up needed once #768 is merged

[RussH]

Is this intended to address a specific GDPR/data-retention requirement, or is it primarily an orphan-record cleanup change?

One related point: we also need to think about reassignment workflows, not just deletion. For example, when recruiters leave, we need to reassign candidate, job order or contact ownership rather than delete the underlying records. That kind of controlled reassignment would be much easier and safer on InnoDB than MyISAM, because we can use transactions, row locking, update/rollback behaviour

[anonymoususer72041]

This PR is intended primarily as an orphan-record cleanup and data-integrity change, not as a GDPR/data-retention implementation.

The goal here is to make the existing entity delete flows leave the database in a cleaner state by removing directly owned related records and resetting references where the current schema already uses a no-link value. I agree that GDPR/data-retention semantics would need to be handled separately, because that would require explicit policy decisions around retention periods, anonymization vs. deletion, auditability and possibly user-facing workflows.

I also agree on the reassignment point. Reassigning candidate, job order and contact ownership when recruiters leave is a separate workflow from deleting the underlying business records and it should probably be addressed in its own issue/PR. That would likely need to cover owner/recruiter fields, permissions, audit/history behaviour and bulk reassignment UX.

The InnoDB point makes sense as well. Controlled reassignment and larger cleanup operations would be safer with transactions and rollback behaviour. I would prefer to keep this PR limited to the current deletion cleanup scope and track reassignment/InnoDB-related workflow improvements separately.