User#case_assignments has misleading dependent: :destroy behavior

[compwron]

Problem

In app/models/user.rb:21:

```ruby
has_many :case_assignments, foreign_key: "volunteer_id", dependent: :destroy # TODO destroy is wrong
```

The `# TODO destroy is wrong` comment has been there for a while, flagging a known but unaddressed issue. Worth investigating and resolving:

1. Cascade may discard history. When a volunteer user is destroyed (or soft-deleted via paranoia), all their `case_assignments` rows are destroyed. `case_assignments` is the join record between volunteers and `casa_cases` and likely carries history (active flag, dates) that should survive the volunteer being deactivated.
2. Interaction with paranoia. The `User` model uses soft-delete in places — `dependent: :destroy` runs `destroy` callbacks on the dependents, which may or may not honor soft-delete depending on each model's setup.
3. Same FK pattern on `case_contacts`, `followups`, `other_duties` at lines 24, 26, 31 deserves the same audit — those have `dependent: :destroy` too and may have the same problem.

What to investigate

• Confirm what should happen to `case_assignments` when a volunteer is deactivated/deleted. Most likely: the assignment should be `active: false` but retained for audit/historical reporting.
• Decide on the right Rails option: `dependent: :nullify` (loses the volunteer link), `dependent: :destroy` with paranoia honoring soft-delete, or no `dependent` and explicit handling in a service.
• Audit the sibling associations on User (`case_contacts`, `followups`, `other_duties`, `learning_hours`, `supervisor_volunteer`, `preference_set`, `address`) for the same question.
• Add a model spec covering the chosen behavior so the contract is enforced.

Acceptance criteria

• The TODO comment is resolved (either by fixing the behavior or by writing down why `:destroy` is correct).
• Spec coverage exists for what happens to `case_assignments` when a volunteer is destroyed/soft-deleted.