fix(consolidator): dedupe + ON CONFLICT for observation_sources INSERT

[youchi1]

Summary

Both _execute_update_action and _execute_create_action in the consolidator insert rows into the observation_sources junction table. Both INSERT sites were missing two safeguards, causing UniqueViolationError on observation_sources_pkey under realistic load:

1. Intra-batch duplicates — source_ids (or source_memory_ids) can contain the same id more than once when several memories collapse to the same effective source. The unfiltered list was passed to executemany, which then hit the unique constraint within the same batch.
2. Concurrent consolidation — two consolidator workers racing on the same observation hit the DELETE-then-INSERT window in _execute_update_action.
3. Residual rows — rare but possible at transaction boundaries when the DELETE doesn't observe a row that the INSERT then collides with.

Fix

• dict.fromkeys(source_ids) (and dict.fromkeys(source_memory_ids)) — preserves insertion order while deduping in-batch.
• ON CONFLICT (observation_id, source_id) DO NOTHING on both INSERT sites — absorbs any surviving duplicate without aborting the batch.

Both layers are needed: dedupe avoids the round-trip on common in-batch duplicates; ON CONFLICT handles cross-batch / concurrent races.

Reproduced in production on a workload that retained sessions with overlapping source memories. After this change, consolidation runs that were previously rolling back per-batch now complete cleanly.

Test plan

• Reproduced UniqueViolationError on observation_sources_pkey on the original code with overlapping source_ids
• Confirmed both INSERT sites are exercised (line ~1029 update path, line ~1416 create path)
• Verified deployed fix on a live system; consolidation no longer raises