Configurable decay thresholds

Hardcoded decay thresholds (90, 180, 120 as magic numbers scattered across cron jobs, cleanup handlers, and segment queries) create three problems. First, they drift: the cron job uses 180 days while the segment query uses 90, causing inconsistent behavior that is invisible until a contact falls into the gap. Second, they cannot be tuned for list behavior without a code deployment — if you discover your audience has a 60-day engagement cycle, changing the threshold requires finding and updating every hardcoded number across multiple files. Third, they make code review harder: a reviewer seeing 120 in a WHERE clause has no context for whether that number is intentional, inherited, or stale.

Centralize all decay thresholds in a single config module, backed by environment variables so they can be adjusted without a code deploy:

// src/lib/config/decay.ts
export const DECAY_CONFIG = {
  atRiskDays:       parseInt(process.env.DECAY_AT_RISK_DAYS       ?? '30'),
  inactiveDays:     parseInt(process.env.DECAY_INACTIVE_DAYS      ?? '90'),
  lapsedDays:       parseInt(process.env.DECAY_LAPSED_DAYS        ?? '180'),
  reverifyAfterDays: parseInt(process.env.REVERIFY_AFTER_DAYS     ?? '120'),
} as const

Import DECAY_CONFIG in every location that previously used a hardcoded number. A grep for numeric literals like 90, 120, 180 in the codebase should return zero results in list-hygiene logic after this change.