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/bold/DESIGN.md

@@ -0,0 +1,55 @@
+---
+name: Bold
+colors:
+  primary: "#0077BC"
+  secondary: "#009866"
+  success: "#16A34A"
+  warning: "#D97706"
+  danger: "#DC2626"
+  surface: "#111111"
+  text: "#111827"
+  neutral: "#111111"
+typography:
+  h1:
+    fontFamily: "Archivo Black"
+    fontSize: 3rem
+  body-md:
+    fontFamily: "Archivo Black"
+    fontSize: 1rem
+  label-caps:
+    fontFamily: "JetBrains Mono"
+    fontSize: 0.75rem
+  sourceScale: "desktop-first expressive scale"
+  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
+rounded:
+  sm: 4px
+  md: 8px
+spacing:
+  sm: 4px
+  md: 8px
+  sourceScale: "4/8/12/16/24/32"
+---
+
+## Overview
+
+Strong visual presence with heavyweight typography, high-contrast colors, and commanding layouts.
+
+## Style Foundations
+
+- **Visual style:** bold
+- **Typography scale:** desktop-first expressive scale
+- **Typography fonts:** primary=Archivo Black, display=Archivo Black, mono=JetBrains Mono
+- **Typography weights:** 100, 200, 300, 400, 500, 600, 700, 800, 900
+- **Color palette:** primary, secondary
+- **Spacing scale:** 4/8/12/16/24/32
+
+## Colors
+
+- **Primary (#0077BC):** Token from style foundations.
+- **Secondary (#009866):** Token from style foundations.
+- **Success (#16A34A):** Token from style foundations.
+- **Warning (#D97706):** Token from style foundations.
+- **Danger (#DC2626):** Token from style foundations.
+- **Surface (#111111):** Token from style foundations.
+- **Text (#111827):** Token from style foundations.
+- **Neutral (#111111):** Derived from the surface token for official format compatibility.

skills/design/design-systems/style-skills/bold/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: bold
+description: Strong visual presence with heavyweight typography, high-contrast colors, and commanding layouts.
+license: MIT
+metadata:
+  author: typeui.sh
+---
+
+<!-- TYPEUI_SH_MANAGED_START -->
+# Bold Design System Skill (Universal)
+
+## Mission
+You are an expert design-system guideline author for Bold.
+Create practical, implementation-ready guidance that can be directly used by engineers and designers.
+
+## Brand
+
+
+## Style Foundations
+- Visual style: bold
+- Typography scale: desktop-first expressive scale | Fonts: primary=Archivo Black, display=Archivo Black, mono=JetBrains Mono | weights=100, 200, 300, 400, 500, 600, 700, 800, 900
+- Color palette: primary, secondary | Tokens: primary=#0077BC, secondary=#009866, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#111111, text=#111827
+- Spacing scale: 4/8/12/16/24/32
+
+
+## Accessibility
+WCAG 2.2 AA, keyboard-first interactions, visible focus states, screen-reader tested labels, reduced-motion support, 44px+ touch targets, high-contrast support
+
+## Writing Tone
+friendly, professional
+
+## Rules: Do
+- prefer semantic tokens over raw values
+- preserve visual hierarchy
+- keep interaction states explicit
+
+## Rules: Don't
+- avoid low contrast text
+- avoid inconsistent spacing rhythm
+- avoid ambiguous labels
+
+## 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.
+
+<!-- TYPEUI_SH_MANAGED_END -->