fix(bridge): skip array properties in keyword-fallback toString()

[steveonjava]

Summary

The bridge's keyword-fallback recall and query endpoints crash with HTTP 500 when any node carries an array-valued property. toString() is undefined for arrays in Neo4j, so the fallback's any(key IN keys(n) WHERE toLower(toString(n[key])) CONTAINS $query) predicate fails as soon as the planner evaluates the embedding key.

Root cause

Both _fallback_search_records() and _fallback_query_records() in server/main.py iterate over all property keys without filtering out array-valued ones. Since the backend writes embedding as a raw DoubleArray, this crashes on essentially every real memory graph.

Fix

Added NOT key IN ['embedding', 'vector'] to the any(key IN keys(n) ...) predicate in both fallback functions. This excludes known list-type keys before toString() is applied.

The fix is a hybrid rather than the obvious one-liner:

• A plain embedding/vector denylist still crashes on any other list property that might appear in the future.
• A pure type guard (valueType(n[key]) IS :: LIST<FLOAT> is crash-safe but silently drops matches for content that only exists inside a list.
• This approach keeps the denylist as a cheap short-circuit for large vectors and coerces remaining lists to searchable text, so array content stays findable.

Test plan

• npm run build
• npm run test:unit
• npm run test:integration
• npm run test:e2e

Behavior / compat notes

• Keyword fallback no longer scans vector properties (which were never meaningfully searchable as strings anyway), so it can no longer 500 on embedded graphs.
• Recall and query return results or an empty list instead of raising. No change for graphs without embeddings.
• No schema change, no API change, no new dependency.