Urgent: replace raw Dewey producer_object_euid usage with external-object references

[iamh2o]

Problem

Bloom registers Dewey artifacts using raw producer_object_euid metadata for Bloom run identity. Cross-service external object references should be represented through Dewey/TapDB external-object and external-object-relation records, not carried as raw *_euid fields.

Evidence

Annotated source comments were added at:

• bloom_lims/domain/beta_lab_stages.py
• bloom_lims/integrations/dewey/client.py

Investigation report: /Users/jmajor/projects/mega_dayhoff/repos_work/daylily-ursa/docs/plans/20260709T234931Z_meridian_euid_integrity_investigation_report.md

Required fix

• Update Bloom-to-Dewey artifact registration to create/reuse Dewey external-object records for Bloom producer identities.
• Attach relations from Dewey artifacts to those external-object records.
• Stop sending Bloom producer identity through producer_object_euid once Dewey exposes the replacement contract.
• Add regression tests preventing fake or generic IDs in *_euid producer fields.

Priority

Urgent. The current pattern depends on a legacy Dewey field that can create misleading object identity semantics.

[iamh2o]

Scope clarification from follow-up audit: the intended and only durable way to connect objects is TapDB lineage. object_euid/producer_object_euid fields should not be used as relationship storage. Cross-system targets should be external-object reference nodes connected by lineage. Source comments now use TODO(lineage-contract).