fix: four silent-failure paths — backend flag ignored, cloud add 400s, failed chunks checkpointed, LongMemEval token budget

[christian4423]

Four independent fixes, all found while running BEAM and the mem0-cloud path. Each one turns a
failure into something that looks like a legitimate result, so none of them are visible in the
output they corrupt. Happy to split into separate PRs if you'd prefer.

Follow-up to #23, which fixed the same token-budget defect in the BEAM runner.

---

1. --backend is unreachable whenever MEM0_BACKEND is set

backend = os.getenv("MEM0_BACKEND", args.backend)

--backend is declared with default="oss", so args.backend is always truthy and the getenv
default is never reached — the environment wins unconditionally. Since load_dotenv(override=True)
pushes .env into the environment, a stale line in a committed .env silently beats an explicit
flag on the command line, and nothing in the logs or results records which backend actually ran.

Cost me ten minutes of a paid run pointed at the wrong backend. Now args.backend or os.getenv("MEM0_BACKEND") or "oss", in both runners. Unchanged when the flag is omitted.

2. Cloud add() posts to /v3/memories/, which is a retrieval endpoint

Returns 400 Filters are required — so --backend cloud ingestion was non-functional, not
merely degraded. Add is /v1/; retrieval correctly stays on /v3/. Both are now env-overridable
so the harness isn't pinned to one API generation. A follow-on: /v1/ wraps its acknowledgement
in a list, so the dict-shaped handler raised AttributeError on the first successful add — also
fixed.

3. A failed ingestion chunk is checkpointed and never retried

chunks_already_done.add(chunk_key) sits outside the if response is not None branch, so a chunk
that failed is recorded as completed and --resume skips it forever. The failure is counted and
logged, but by the time anyone reads that warning the gap is permanent — the only record of which
chunks are missing is the checkpoint that just claimed them.

We hit this on BEAM 1M: one conversation ingested at 6.5 memories/chunk against 15.9 and
15.8 for its two siblings — same domain, same chunk count, slightly higher fact density.
Re-ingesting brought it to 15.8 (1,703 → 4,143 memories), confirming ~55% had been silently
dropped. total_chunks_failed read 0 the entire time.

4. LongMemEval answerer/judge inherit max_tokens=4096

answerer.generate (:593, :759) and judge_llm.generate_structured (:700, :816) pass no
max_tokens, inheriting LLMClient's 4096. --answerer-model and --judge-model both default to
gpt-5, and reasoning models bill reasoning against max_completion_tokens — so a long answer
exhausts the budget on reasoning alone and returns an empty string, which scores 0.0 and is
indistinguishable from a wrong answer.

⚠️ This is the path your published 91.0% is measured through — the README states the LongMemEval
runs used GPT-5 as answerer and judge. On BEAM the identical fix moved five arms by +0.010 to
+0.047 and took empty answers from 20 to 0. Worth a re-run before the next publication.

---

Verification

• fix: GPT-5 & o-series compatibility — handle rejected max_tokens and temperature params #1 — precedence table checked directly: --backend cloud with MEM0_BACKEND=oss now resolves
  to cloud (previously oss); env still honoured with no flag; default preserved with neither.
• fix: add GPT-5-safe eval rejudge flows for LOCOMO and LongMemEval #2 — verified by a live mem0-cloud run: 60 BEAM questions, 0 errors, avg_score=0.559.
  Before the fix every cloud add failed with the 400 above.
• Fix _search_oss payload structure for mem0 v2.0.0 compatibility #3 — the 1,703 → 4,143 re-ingest above, on a corpus that had reported zero failed chunks.
• Closed: opened in error #4 — same shape as fix: answerer/judge inherit max_tokens=4096, silently scoring reasoning-model runs 0.0 #23, same constants (16384 / 8192).

Scope is deliberately narrow: three files, no new dependencies, no behaviour change when the
relevant flags and env vars are left alone.