Preference Cooldown Bypass Bug

Problem

Using a preference record's updatedAt timestamp for rate limiting allows users to bypass cooldowns by toggling the preference on/off. This creates a security vulnerability where spam prevention can be circumvented.

Context / Trigger Conditions

• Rate limiting implemented using preference updatedAt field
• Users can toggle preferences (enable/disable) that also track cooldown state
• Cooldown resets unexpectedly when user changes preference settings
• Email or notification spam occurs despite cooldown being in place
• Code pattern: if (preference.updatedAt > cooldownThreshold) for rate checks