fix(recall): keep the trace id when the endpoint filters

[MXAntian]

The bug

/recall answers trace_id: null on every filtered call — which is every call any real caller makes.

recallTrace rides on the returned array as a non-enumerable property, and Array.prototype.filter builds a new array. Reading it after min_importance / level / require_vec yields undefined.

Measured against a live server before the fix:

no filters      trace_id = "7defe884-7ecf-4a54-85d1-6e4c0c94e291"
min_importance  trace_id = null
hook-shaped     trace_id = null

Both hooks send min_importance and level on every call, so the id was present only in the unfiltered case nobody uses.

Why it stayed quiet

The trace is persisted either way. recall_traces fills with rows no caller can name — from inside the DB the instrumentation looks healthy.

The consequence is that the citation contract only has a first half. Every recall ships:

<memory-citation-contract trace-id="…" allowed-ids="…">
Only cite [id:N] values listed in allowed-ids. Validate generated citations
against this trace before publishing.
</memory-citation-contract>

…and then get_recall_trace / validate_memory_references have nothing to be called with, because the caller that would call them never received an id.

Fix

Capture the trace before the filters instead of after.

Test

Asserts the id survives min_importance, level, and the exact shape both hooks send. Without the fix those three go red while the unfiltered case still passes — that asymmetry is what hid it:

✗ trace id survives min_importance — trace_id=null hits=2
✗ trace id survives level — trace_id=null hits=2
✗ trace id survives the shape both hooks send — trace_id=null hits=2

Full suite: 284 passed / 0 failed.

🤖 Generated with Claude Code