web-ui: CollectionPayload enum literals duplicate mcp-server's zod schema with no shared source of truth #22

Summary

packages/xberg-web-ui/src/lib/types.ts's CollectionPayload type hardcodes distance_metric/index_method as string-literal unions that currently match CollectionPayloadSchema's zod enum in mcp-server/src/http/collection-route.ts exactly — but the two packages don't share a type or schema definition, so they can silently drift on future changes (e.g. adding a new distance metric server-side without updating the client type, or vice versa).

Flagged by CodeRabbit on PR #20 and intentionally not fixed inline — it's a cross-package architectural change, not a quick fix.

Current state

• Server-side: mcp-server/src/http/collection-route.ts — CollectionPayloadSchema (zod)
• Client-side: packages/xberg-web-ui/src/lib/types.ts — CollectionPayload (hand-written literal union)

Suggested remediation (either)

1. Extract the distance_metric/index_method enums into a small shared module consumed by both mcp-server and packages/xberg-web-ui, so there's a single source of truth.
2. If sharing the schema directly isn't feasible (separate build/publish boundaries), add a lightweight contract test that asserts the client's literal unions equal the server's zod enum values, so drift fails CI instead of failing silently at runtime.

Why this matters

If the server adds/renames a distance_metric or index_method value without updating the client type, TypeScript won't catch it (the client type isn't derived from the server schema), and the mismatch would only surface as a runtime validation error on /collection requests using the new value.