Query-space fixtures gain entity membership via document_entity_id instead of mentions

[fazpu]

Found by adversarial review of #249 (Codex finding 4 "Medium"; Grok finding 4
"Low-medium"). Both reviewers reached it independently. Test fidelity, not a shipped
defect.

What #249 did

Resolution fixtures were failing because memory_v1.entities_current membership requires
surviving provenance, and several corpora seeded entities and aliases with no live
document lineage. #249 gave them provenance through the document-entity bridge arm — a
documents row with document_entity_id pointing at the entity.

That arm is real (p9_01_0022), so the fixtures are not lying about the schema. But it is
the wrong arm for these entity types.

The problem

documents.document_entity_id is specifically the bridge to a Document-typed registry
entity. Real extracted Person / Organization / Concept entities enter entities_current
through chunk-backed mentions and resolution decisions — the mention arm.

Consequence: a regression that breaks real mention-based provenance leaves these
resolution and retrieval suites green via an arm production rarely uses for these types.
The suites stop guarding the path that actually matters.

Affected fixtures include test_retrieval_batch_b.py, test_retrieval_batch_d.py,
test_envelope_contract.py, test_surfaces_parity.py, test_retrieval_api.py,
test_s58_consumption.py.

Proposed fix

Seed valid document / version / representation / chunk / mention / resolution_decision
coordinates — or reuse the real chain fixture — and reserve document_entity_id for
Document entities. A single shared helper would keep it one line per fixture. Envelope and
recipe fixtures that already plant full relation_evidence chains are the better pattern
to copy.

Note on a separate claim

Whether real-user resolution works was verified independently of these fixtures, by
running the real E0-E3 chain and confirming the resulting entities appear in both
memory_v1.entities_current and entity_aliases_current. Codex agreed this issue "does
not itself show that current real-user resolution is broken". This issue is about the
fixtures not being honest evidence for that claim — the claim itself rests on the chain
probe.

Grok additionally noted a related weakening in test_retrieval_batch_d.py
(test_question_context_bounds_exact_alias_fanout_before_confirmation): after the fixture
gained provenance, the assertions only require the output cap of 20 plus
truncation.truncated. If someone removed the nomination LIMIT before
_CONFIRM_CONTEXT_ENTITIES while keeping the output slice, the test would still pass even
though confirmation received all 30 ids — which is exactly the unbounded confirmation
parameter set the docstring says it guards.