fix(register): carry source_url into artifact metadata for AI-BOM downloadLocation

[christophergeyer]

Problem

roar register's batch artifact payload (prepare_batch_registration_artifacts) only sent hashes, size, source_type, and session_hash — it dropped the artifact's source_url. A source-tracked input (e.g. an s3:// dataset pulled through the roar proxy) therefore reached GLaaS with a sourceType but no distribution URL, so the CycloneDX AI-BOM could not emit the downloadLocation external reference. This capped AI-BOM completeness at 97.5 instead of 100 for otherwise-complete pipelines.

Fix

Fold source_url into the artifact entry's metadata JSON when it carries a valid remote source_type. GLaaS stores input.metadata verbatim, and the BOM builder reads metadata.source_url to emit the distribution external reference.

• One function changed: roar/application/publish/registration.py → prepare_batch_registration_artifacts.
• Guarded on a normalized remote source type (s3/gs/https/hf); merges into any existing metadata without clobbering.

Verification

• Unit-level: the prepared payload for an s3 input now includes metadata: {"source_url": "s3://…"} alongside source_type: "s3".
• End-to-end (dev-instrumented): confirmed prepare_batch_registration_artifacts emits the metadata for the s3 input during a real roar register.

Cross-repo dependency (for a live 100)

This roar change is necessary but not sufficient on its own. The GLaaS-api staged/bearer registration path (registration-sessions/:id/artifacts/batch) must persist sourceType + metadata. That handling is present on glaas-api main (artifact.service.ts registerBatchUnderRegistrationSession) but not yet on the deployed prod image — prod stores sourceType: null and metadata without source_url. A glaas-api prod deploy of main is required alongside this fix.

Release

Targets rc/0.4.1 (fast-follow). Not published to PyPI yet — used to generate the treqs.ai AI-BOM example on the 0.4.1 rc.