Scoring model documented and versioned

A scoring model that lives as scattered contact.score += 10 calls across twelve event handlers cannot be audited, cannot be versioned, and cannot be changed without grepping the entire codebase for every increment site. iso-25010:2011 maintainability.analysability formalizes the problem: the system is not analyzable without exhaustive code review. In practice, this means sales teams receive qualified leads whose score no one can explain, scoring bugs are introduced by developers who miss a call site, and there is no record of what the model was when a particular lead was scored — critical when a lead disputes their classification or when an audit demands a scoring rationale.

Create a single scoring config module at src/lib/scoring/lead-score-model.ts (or equivalent). Every score-modification call site must reference it — no magic numbers in event handlers.

// src/lib/scoring/lead-score-model.ts
export const SCORE_MODEL_VERSION = '1.2'

export const SCORE_EVENTS = {
  email_opened:       { points: 1,   reason: 'MPP unreliable — low weight' },
  email_clicked:      { points: 5,   reason: 'Reliable intent signal' },
  email_replied:      { points: 10,  reason: 'Highest engagement signal' },
  page_visit:         { points: 2,   reason: 'Tracked via UTM' },
  pricing_page_visit: { points: 8,   reason: 'High-intent page' },
  demo_booked:        { points: 20,  reason: 'Explicit intent' },
  email_unsubscribed: { points: -50, reason: 'Hard negative — suppress' },
} as const satisfies Record<string, { points: number; reason: string }>

Bump SCORE_MODEL_VERSION every time a point value or event type changes. Audit that at least 90% of score-modification call sites import from this module rather than hardcoding values.