Phase 0 foundation: canonical schema, ingest pipeline, CRM MCP server

Workstream A–C substrate for the Ten31 agentic system:
- A1: docs/crm-overview.md; CLAUDE.md conventions + guardrail #9
- A2: additive/reversible core migration (canonical_entities, entity_links,
  interaction_log, relationship_edges, soft-delete) + ledgered runner
- B1/B3: chunking + deterministic entity resolution (backend/ingest)
- B2: dense (bge-m3) + BM25 sparse ingest to Qdrant crm_chunks
- C: CRM MCP server (reads, retrieval modes, logged writes) — no outbound tools
- docs: redaction/re-hydration, Gmail enablement runbook
- synthetic test data; .env.example; housekeeping (.gitignore, untrack crm.db,
  drop legacy files + start9/0.3.5)

Verified end-to-end on synthetic data + live Sparks (hybrid > dense on entity
queries). Real backfill runs on Ten31 infra; index holds synthetic data only.
Branch snapshot also captures pre-existing working-tree changes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

start9/0.4/startos/versions/v0.1.0.43.ts

@@ -0,0 +1,44 @@
+import { VersionInfo } from '@start9labs/start-sdk'
+
+// Hotfix for 0.1.0:42.
+//
+// Issue 1 (critical): POST requests to /api/email/* hung indefinitely.
+// server.py's do_POST called get_body() early in the dispatch to support
+// /api/auth/login, which reads bytes off the request stream. My Gmail
+// integration hook then ran route handlers that called get_body() a
+// second time — but the stream was already drained, so the second read
+// blocked waiting for bytes that never came. GET requests (which don't
+// read a body) were unaffected.
+//
+// Fix: get_body() now caches the parsed JSON on the handler instance
+// on first call. Repeat calls return the cached value. Handler
+// instances are per-request in ThreadingHTTPServer, so the cache is
+// naturally request-scoped and thread-safe.
+//
+// Issue 2 (minor): the /api/email/accounts/enroll endpoint required
+// both `email_address` and `user_id` in the body, making it painful to
+// call for the common single-admin-enrolling-themselves case.
+//
+// Fix: the endpoint now also accepts `email` as an alias, and if
+// user_id isn't supplied it auto-resolves by looking up the email in
+// the users table (falling back to the authenticated admin's own id
+// if no match).
+//
+// No schema changes, no data migration.
+export const v_0_1_0_43 = VersionInfo.of({
+  version: '0.1.0:43',
+  releaseNotes: {
+    en_US: [
+      'Hotfix for the Gmail integration in 0.1.0:42. POST requests to',
+      '/api/email/* endpoints were hanging because the request body was',
+      'being read twice from a single-shot stream. This release caches',
+      'the parsed body on the request so subsequent reads are safe, and',
+      'also relaxes the enroll endpoint to accept just an email and',
+      'auto-resolve the CRM user.',
+    ].join(' '),
+  },
+  migrations: {
+    up: async () => {},
+    down: async () => {},
+  },
+})