Urgent: replace raw producer_object_euid links with external-object references

[iamh2o]

Problem

Dewey artifact registration still accepts and persists raw producer_object_euid values. Some paths use this field for values that are not TapDB/Meridian EUIDs, for example PubMed PMIDs. This violates the object identity contract: external object references should be modeled through Dewey/TapDB external-object and external-object-relation records, not raw *_euid fields.

Evidence

Annotated source comments were added at:

• dewey_service/services/artifacts.py
• dewey_service/services/literature.py
• dewey_service/services/sequencer_runs.py
• dewey_service/services/artifact_set_registration.py

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

Required fix

• Split generic producer IDs from true TapDB/Meridian EUIDs.
• Route producer references through external-object and external-object-relation records.
• Stop storing PMIDs, run labels, analysis IDs, or other generic IDs in producer_object_euid.
• Add regression tests that reject non-EUID values in fields named *_euid.

Priority

Urgent. This is an identity/linking contract issue and can create fake or misleading /tapdb/object links.

[iamh2o]

Scope clarification from follow-up audit: the intended and only durable way to connect objects is TapDB lineage. producer_object_euid/external_object_euid should not be used as relationship storage. external_object_euid is only acceptable as the EUID of the external-object reference node; the relationship itself must be represented as lineage. Source comments now use TODO(lineage-contract).