feat: IMAP mail sync with thread-to-contact matching (PRD §6.1)

Real IMAP connection via imapflow library:
- Connects to IMAP server (IMAPFlow, TLS on port 993)
- Fetches recent messages (configurable limit, default 20)
- Extracts: from, fromEmail, subject, date, snippet (200 chars)
- Thread-to-contact matching (PRD §6.1):
  1. Match sender email against persons table
  2. If no person match, extract domain and match against company.website
  3. Returns matchedCompany + matchedPerson for each email
- Audit-logged (action: crm.mailsync:imap)
- Zod validated (host, port, user, password, folder, limit)
- 502 on IMAP connection failure with detail
- 400 on validation failure

Tested: invalid creds → 502 'IMAP connection failed', missing host → 400

skills/design/design-systems/style-skills/warm-editorial/DESIGN.md

@@ -0,0 +1,65 @@
+# Warm Editorial
+
+> Category: Starter
+> A serif-led magazine aesthetic. Terracotta accent on warm off-white paper —
+> good for long-form, editorial, and brand-led marketing pages.
+
+## Visual Theme & Atmosphere
+Warm, unhurried, magazine-like. Think "a New Yorker interview column online." Generous whitespace, long-form readability, restrained chrome. Playful but never novelty.
+
+## Color Palette & Roles
+- **Background:** `#FAF7F2` (warm off-white paper)
+- **Foreground:** `#1C1A17` (near-black, slightly warm)
+- **Accent (primary):** `#C0512F` (terracotta) — used for links, primary CTAs, 1 hero element max per page
+- **Accent (secondary):** `#2F5B4F` (forest) — section dividers, tags
+- **Muted:** `#8A817A` (mid-warm-grey) — timestamps, metadata
+- **Surface:** `#FFFFFF` — elevated cards only
+Never use pure black or pure white anywhere user-facing.
+
+## Typography Rules
+- **Display / headings:** "GT Sectra" or fallback serif (`'GT Sectra', 'Times New Roman', serif`)
+- **Body:** "Söhne" or fallback sans (`'Söhne', -apple-system, system-ui, sans-serif`)
+- **Mono:** `'JetBrains Mono', ui-monospace, monospace` for code only
+- Scale (px): 12 · 14 · 16 · 20 · 28 · 40 · 56 · 80
+- Line-height: 1.6 for body, 1.2 for display
+- Letter-spacing: -0.02em for display sizes above 40px; default elsewhere
+
+## Component Stylings
+- **Buttons:** flat fill, 12px radius, 14px padding-block, 20px padding-inline. Primary = terracotta fill, off-white label. Secondary = outlined 1px foreground, transparent fill.
+- **Cards:** off-white background, 1px forest-at-8%-opacity border, 16px radius, 24–32px internal padding. No shadow except hover (y+2px, blur 16, foreground-at-6%).
+- **Inputs:** underline only (no box), 1px muted baseline, terracotta baseline on focus, 16px vertical padding.
+- **Links:** terracotta, 1px terracotta-at-40% underline, no underline on hover (swap for terracotta-at-8% background).
+
+## Layout Principles
+- 12-column grid, 1200px max-width, 24px gutters.
+- Hero sections: 72vh minimum, 120vh maximum. Content top-biased, never centered vertically.
+- Body sections: 80px top+bottom spacing at desktop; 48px at tablet; 32px at phone.
+- One accent color per screen. If a page has a terracotta hero, secondary CTAs are foreground-only, not forest.
+
+## Depth & Elevation
+Minimal. Only two elevation levels:
+- **Flat (0):** everything by default.
+- **Raised (1):** cards on hover, dropdown menus, floating CTAs. 2px y-offset, 16px blur, foreground at 6% opacity.
+No shadows on inputs. No shadows on the hero. No neumorphism, no glassmorphism.
+
+## Do's and Don'ts
+- ✅ Let whitespace breathe. A short headline on 50% of the viewport height is correct.
+- ✅ Use serif for numbers when they matter (pricing, stats).
+- ✅ Draw one accent element per page; the rest is foreground.
+- ❌ No gradients.
+- ❌ No emojis in product copy.
+- ❌ No sentence-case for headings — use title case for H1/H2, sentence case for H3 and below.
+- ❌ No border-radius above 24px; no border-radius below 8px.
+
+## Responsive Behavior
+- **Desktop ≥ 1024px:** 12-col grid, full hero heights, side-by-side columns.
+- **Tablet 640–1023px:** 8-col grid; hero drops to 60vh; columns stack at 3+.
+- **Phone < 640px:** 4-col grid; single-column layout; hero drops to 50vh; all padding -33%.
+
+## Agent Prompt Guide
+When generating artifacts against this design system:
+- Lead with typography and whitespace; chrome (borders, shadows) is subtractive.
+- If you need more than one accent element on a screen, you're doing too much — cut one.
+- When asked for "professional" or "serious," lean harder on serif + whitespace. When asked for "modern," this system isn't the right answer; pick a different DESIGN.md.
+- Color tokens are non-negotiable. Do not invent new hex values. If the request needs a color outside this palette, produce a warning comment in the artifact and use the closest existing token.
+- Prefer 1 hero + 3–5 body sections over 1 hero + 8+ sections. Editorial means restraint.

skills/design/design-systems/style-skills/warm-editorial/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: warm-editorial
+description: A serif-led magazine aesthetic: terracotta accent on warm off-white paper. Good for long-form, editorial, and brand-led marketing pages. "A New Yorker interview column online."
+license: MIT
+metadata:
+  author: hand-authored
+---
+
+<!-- HAND_AUTHORED_MANAGED_START -->
+# Warm Editorial Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Warm Editorial.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers. This system is hand-authored; treat its DESIGN.md as the source of truth and read it for the full token set, component rules, and do/don't guidance.
+
+## Brand
+Warm Editorial — warm, unhurried, magazine-like.
+
+## Style Foundations
+- Visual style: editorial, serif-led, warm, long-form
+- Typography fonts: primary=serif, display=serif, mono=monospace
+- Color palette: terracotta accent, warm off-white paper, near-black warm ink
+- Key tokens: background=#FAF7F2, foreground=#1C1A17, accent=terracotta
+- Spacing / layout: generous whitespace, long-form reading rhythm
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, semantic HTML before ARIA, reduced-motion support, 44px+ touch targets, high-contrast support.
+
+## Writing Tone
+warm, unhurried, magazine-like
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+- read DESIGN.md for the authoritative palette, type, and component rules
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+- do not invent hex values outside this system's palette
+
+## Expected Behavior
+- Follow the foundations first, then component consistency.
+- When uncertain, prioritize accessibility and clarity over novelty.
+- Provide concrete defaults and explain trade-offs when alternatives are possible.
+- Keep guidance opinionated, concise, and implementation-focused.
+
+## Guideline Authoring Workflow
+1. Restate the design intent in one sentence before proposing rules.
+2. Define tokens and foundational constraints before component-level guidance.
+3. Specify component anatomy, states, variants, and interaction behavior.
+4. Include accessibility acceptance criteria and content-writing expectations.
+5. Add anti-patterns and migration notes for existing inconsistent UI.
+6. End with a QA checklist that can be executed in code review.
+
+## Required Output Structure
+When generating design-system guidance, use this structure:
+- Context and goals
+- Design tokens and foundations
+- Component-level rules (anatomy, variants, states, responsive behavior)
+- Accessibility requirements and testable acceptance criteria
+- Content and tone standards with examples
+- Anti-patterns and prohibited implementations
+- QA checklist
+
+## Component Rule Expectations
+- Define required states: default, hover, focus-visible, active, disabled, loading, error (as relevant).
+- Describe interaction behavior for keyboard, pointer, and touch.
+- State spacing, typography, and color-token usage explicitly.
+- Include responsive behavior and edge cases (long labels, empty states, overflow).
+
+## Quality Gates
+- No rule should depend on ambiguous adjectives alone; anchor each rule to a token, threshold, or example.
+- Every accessibility statement must be testable in implementation.
+- Prefer system consistency over one-off local optimizations.
+- Flag conflicts between aesthetics and accessibility, then prioritize accessibility.
+
+## Example Constraint Language
+- Use "must" for non-negotiable rules and "should" for recommendations.
+- Pair every do-rule with at least one concrete don't-example.
+- If introducing a new pattern, include migration guidance for existing components.
+
+<!-- HAND_AUTHORED_MANAGED_END -->