fix(attribution): group Snag referral codes as 'Snag Referrals'

[Crypt0Shmipt0]

Diagnosis (from Tomer)

The 6-char alphanumeric values dominating the channels list (axeheq, 9pu7bd, 3VAN8Y, etc.) are all Snag referral codes that arrive via ?ref=XXX URLs. Example: https://airdrop.shiftrwa.xyz/register?ref=3VAN8Y.

Sprint 2.0 backfill captured these and wrote them into first_utm_source for many profiles. Result:

• 50 separate pseudo-channels (one per code) dominating the chart
• percentWithUtm inflated to 66.5% (still a lie — most of those are referrals not UTMs)

Fix

Backend regex ^[a-zA-Z0-9]{6}$ collapses all 6-char codes:

Function	Behavior
computeChannelROI	Codes become single channel snag_referrals instead of 50+ rows
computeAttributionCoverage	Codes counted toward withReferralOnly, NOT withUtm
computeTopCampaigns	Defensive filter excludes 6-char pattern from campaign field

Frontend formatSource() maps snag_referrals → "Snag Referrals" for display.

Expected outcome after deploy

Channels (before):
  direct          5,388
  axeheq            512
  9pu7bd            375
  ... 47 more codes

Channels (after):
  direct          5,388
  snag_referrals  ~10,000  ← rolled up
  (real UTM sources appear here as Sprint 2.3 data accrues)

Coverage:
  before: percentWithUtm = 66.5%  (still wrong)
  after:  percentWithUtm = ~0-1%  (honest — Sprint 2.3 has been live 2h)
  before: withReferralOnly = 65
  after:  withReferralOnly = ~10,000+  ← reflects the real Snag referral funnel

Tests

• Backend: 66/66 pass
• Frontend: 48/48 pass
• Both builds clean

Test plan

• Merge → Render redeploy
• curl /api/attribution/overview → channels has snag_referrals row, no 6-char rows
• coverage.percentWithUtm < 5%, withReferralOnly >> withUtm
• Source Attribution tab → "Snag Referrals" appears in channels card, coverage ring shows honest tiny %UTM

🤖 Generated with Claude Code