[BE-87] Soft delete for member-facing records instead of hard delete

[yusuftomilola]

Overview

Deletions across the API appear to be hard deletes. For a system holding bookings, invoices, and attendance, that destroys financial and audit history and can cascade unexpectedly.

Tasks

• Add TypeORM @DeleteDateColumn() to user-facing entities where history matters: users, bookings, invoices, workspaces, membership plans.
• Switch delete endpoints to softRemove/softDelete; ensure default queries exclude soft-deleted rows.
• Add an admin-only restore endpoint and an includeDeleted query flag for admin listings.
• Confirm unique constraints still behave sensibly (e.g. a soft-deleted email should not permanently block re-registration — decide and document the rule).
• Generate a migration.

Acceptance Criteria

• Deleting a booking hides it from listings but preserves the row and its invoice linkage.
• Admin can restore a soft-deleted record.
• Re-registering with a soft-deleted user's email behaves per the documented rule and is covered by a test.

Dependencies

Complements BE-67 (audit trail).

Notes for Contributors

Comment below to be assigned.