fix(python): tolerate server response fields the SDK does not declare (#161)

[salishforge]

Fixes #161.

Far worse than filed

The issue framed this as an explain-only edge case. In fact client.query() has been broken on every non-empty response since v3.8 — all four warm-tier SELECT paths emit context_signals, epistemic_status and evidence_count unconditionally (all three are NOT NULL columns), and app.ts passes rows through unprojected. Since the SDK builds results with Cls(**raw), every one of those raises TypeError.

Four more types are affected:

Type	Missing fields	Breaks on
QueryResult	context_signals, epistemic_status, evidence_count, explanation	every non-empty query
SleepCycleResult	13 fields	every /sleep (4 are unconditional)
MemoryHealth	stale_memory_count, avg_staleness, knowledge_gap_count_7d	every /health
ConsolidateResult	batchesProcessed	every /consolidate (both return paths)
AgentStats	stale_embedding_count	when embeddings are enabled

Verified empirically by running the pre-fix dataclasses against realistic current payloads — all four raise TypeError.

Both halves, because either alone is insufficient

• from_response() drops keys the dataclass doesn't declare, so the next server field can't break callers again.
• The missing fields are declared with defaults, so the new data is actually readable and an SDK newer than its server still parses.

Filtering alone would have parsed cleanly while silently discarding every v3.8–v3.12 field — arguably worse than the crash, since it fails invisibly.

One deliberate break

QueryResult.summary moves after rank so it can carry a default. Shared-pool rows set summary: pr.summary ?? undefined, which JSON.stringify drops, so the key can be absent entirely — meaning summary cannot remain a required positional argument. This changes positional construction. Judged acceptable: the package is unpublished at 0.1.0 (no PyPI workflow), and it's a deserialization result type. The alternative was defaulting five fields that are always present, i.e. defensive code for cases that cannot occur.

The real work: a test harness that did not exist

The Python SDK had zero tests and CI has never run Python — which is precisely how a total breakage of client.query() survived five releases. This adds:

• 65 tests — realistic current payloads per type, older-server payloads with the new fields absent (proving the defaults work), and an unknown-future-field guard per type: the test that would have caught this bug.
• A CI job on Python 3.10 and 3.13, the bounds pyproject.toml claims to support. Parsing-layer only — no server, no Postgres, runs in seconds.

Left alone deliberately

resilient.py converts these parse errors into silently-empty results, so callers saw "no memories" rather than an error. Documented in its docstring but unchanged — whether a parse error should be treated as a transport failure deserves its own decision, not a drive-by change.

🤖 Generated with Claude Code

https://claude.ai/code/session_011xCqQo49d3CEbn6oEvb3Ru