Solo entity-detail can persist a different id than the requested task id (no id-pinning)

[daviburg]

[@pm]

Summary

The entity-detail extraction path can persist entity data under a different id than the one requested, because the SOLO detail path does not pin/verify the returned id against the requested task id. Surfaced during the adversarial review of PR for #524 — this is pre-existing and not a regression introduced by #524.

Problem

In tools/semantic_extraction.py:

• The BATCH entity-detail path has an unexpected-id guard (around L4518–4522) that catches ids the model was not asked about.
• The SOLO entity-detail path (_coerce_entity_fields ~L4334, _validate_entity_detail ~L4370) validates schema only. It does not require entity_data["id"] == get_entity_id(entity_ref).

As a result, after a clean, validated discovery, the solo detail model can return entity data for a different id, and merge_entity (~L5584 / ~L5770) will append/update the wrong entity.

Concrete repro (from the adversarial proof)

1. Clean, validated discovery for an existing entity char-mara-veylin.
2. Solo detail model returns valid (schema-passing) entity data for char-mara-baker (not in catalog).
3. merge_entity appends char-mara-baker — an entity that was never discovered and was not the requested task id.

Suggested fix

Before every entity-detail merge_entity, fail closed unless the returned id matches the requested task id — or pin/overwrite the returned id to the requested id before validation/merge. Apply this uniformly to both the solo and batch paths so the guard behavior is consistent.

Notes

• Pre-existing; not introduced by Dedup quality: residual coreference fragmentation (same entity split across catalog ids; PC split) — post-run review #524.
• Surfaced by the Dedup quality: residual coreference fragmentation (same entity split across catalog ids; PC split) — post-run review #524 adversarial review.
• Related guard already exists on the batch path (L4518–4522) — the solo path lacks the equivalent.

Label: bug