feat: add Voyage AI embedding provider — closes #1

[TerminalGravity]

Adds Voyage AI as a third embedding provider option alongside local (Xenova) and OpenAI.

Changes

• src/lib/embeddings.ts — new VoyageEmbeddingProvider class (voyage-3 model, 1024 dims, 128 texts/batch)
• src/lib/config.ts — extended EmbeddingProvider type and config interface with voyage_api_key / voyage_model
• src/lib/timeline-db.ts — TimelineConfig and getEmbedder() updated to support voyage
• src/tools/onboard-project.ts — accepts voyage_api_key and voyage_model params
• tests/lib/embeddings.test.ts — 3 new tests for voyage provider creation
• README.md — documented VOYAGE_API_KEY, VOYAGE_MODEL env vars and config.yml options

Usage

export EMBEDDING_PROVIDER=voyage
export VOYAGE_API_KEY=pa-...
# optional: VOYAGE_MODEL=voyage-3-lite

Or in .preflight/config.yml:

embeddings:
  provider: voyage
  voyage_api_key: pa-...
  voyage_model: voyage-3

Closes #1

[TerminalGravity]

Clean implementation. The batch-by-128 approach matches Voyage's API limits, and sorting by index before collecting is the right call since the API doesn't guarantee ordering.

A few things:

1. Dimensions are model-dependent — voyage-3 is 1024-dim, but voyage-code-3 is also 1024 while voyage-3-lite is 512. Hardcoding dimensions = 1024 means swapping models via config could silently produce wrong-sized vectors in LanceDB. Consider fetching dimensions from a model→dim map or making it configurable.

2. input_type: "document" — this is correct for indexing, but queries should use input_type: "query". The embed() method (used for search queries) goes through embedBatch which always sends "document". Voyage's docs say this asymmetry matters for retrieval quality.

3. Rate limiting — no retry/backoff on 429s. The OpenAI provider doesn't have this either so it's consistent, but worth noting for heavy onboarding runs.

None of these are blockers for a first pass, but the input_type one is worth fixing before merge — it'll measurably impact search quality.