Fix notification & audit trail for dataclip retention policy changes

[taylordowns2000]

Description

This PR fixes #5088 by checking for a change in the retention_policy when deciding whether to send the policy change alert. The new functionality in this PR:

1. should properly send the email (not stay silent on critical changes!)
2. should not send misleading information about i/o retention periods when the i/o policy is set to :erase_all

The PR also fixes #5090 (the audit trial) in exactly the same fashion.

Validation steps

1. Change only the retention policy, don't touch the retention periods.
2. See the email.
3. Log in as a super user.
4. Check the audit trail.
5. See the appended audit trail entry.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Security Review ✅

• S0 (project scoping): N/A — the change only extends which changeset keys (:retention_policy) trigger an existing notification helper inside Projects.update_project; no new queries or web-layer entrypoints.
• S1 (authorization): N/A — no new controllers, LiveView events, or policy-gated actions; caller authorization for update_project is unchanged.
• S2 (audit trail): PASS — retention-policy changes are still audited via the pre-existing Audit.derive_events(changeset, user) step at lib/lightning/projects.ex:617; this PR only affects email notifications.

[taylordowns2000]

we didn't count changing the policy as part of the retention_setting_updated? function