fix(zep): normalize bare YYYY-MM-DD createdAt to ISO 8601

[ShabanShaame]

Summary

Zep Cloud's /api/v2/graph-batch endpoint rejects bare date strings (e.g. "2025-01-03") with a misleading 400 invalid json error, even though the payload is valid JSON. Datasets that store dates without a time component (common for daily-bucketed corpora) cannot be ingested through ZepProvider.ingest() as a result.

This patch normalizes bare YYYY-MM-DD values to midnight UTC before building each Zep.EpisodeData. Full ISO strings pass through unchanged.

Repro (minimal)

import { ZepClient } from "@getzep/zep-cloud"
const client = new ZepClient({ apiKey: process.env.ZEP_API_KEY! })
await client.graph.create({ graphId: "repro", name: "repro" })
await client.graph.addBatch({
  graphId: "repro",
  episodes: [{ type: "message", data: "user: hi", createdAt: "2025-01-03" }],
}) // throws BadRequestError: invalid json

Behavior table

Zep Cloud, SDK @getzep/zep-cloud, observed 2026-04-20:

createdAt value	Result
"2025-01-03"	400 invalid json
"2025-01-03T00:00:00Z"	200 OK
omitted	200 OK (server fills now)

The error message is misleading — the payload is valid JSON; Zep's validator folds date-format failures into the generic "invalid json" response.

Context

Discovered while running Structured Recall Bench against the zep provider. SRB's dataset sessions carry metadata.date = "YYYY-MM-DD". With this fix, the full 130-question benchmark runs cleanly against Zep Cloud (composite 0.332, ingestion ~15 min, no API errors).

Test plan

• Reviewer runs the minimal repro above against Zep Cloud to confirm the 400 without the patch
• Reviewer runs memorybench with -p zep against a dataset whose sessions carry bare YYYY-MM-DD dates and confirms ingestion no longer 400s