fix(registration): accept hf artifacts in the validator

[christophergeyer]

roar put … hf:// stamps the published artifact source_type="hf" (put_execution.py:656, since 0.4.2). The publish path's own allowlist _VALID_REMOTE_SOURCE_TYPES has accepted hf since #35, and glaas-api has accepted it since June. VALID_SOURCE_TYPES in core/validation.py — applied to every primitive artifact registration — never learned it, and has not changed since the initial commit.

Why nobody noticed

The failure is quiet. A staged artifact that fails validation is skipped, not rejected:

if not validation:
    self._logger.warning("Skipping invalid staged artifact: %s", error_msg)
    errors.append(error_msg)
    continue

So an HF publish uploaded the file, reported success, and dropped that artifact's source from the registration. Rows still looked green — the output is already registered as a local artifact (source_type=None) during the traced step, and the download location rides on a scoped label (a514e77) rather than on source_type. The only symptom is a Registration completed with errors line that reads as noise.

Changes

• add "hf" to VALID_SOURCE_TYPES
• derive the rejection message from the set — it hardcoded "must be 's3', 'gs', 'https', or None" and would have gone stale again on the next scheme
• tests/core/test_validation_source_types.py pins the validator's set against the publish path's, so a scheme cannot be half-added a third time

Verification

Built a wheel from this branch and ran a real delegated publish to HF against prod glaas-api.

Before — Artifact 0 (672314521e56): source_type must be 's3', 'gs', 'https', or None, got 'hf', then Registration completed with errors.

After — clean publish, Reproducibility 7/7, lineage saved on glaas.ai · 1 files · published to hf://…, job exit 0, lineagePublicationStatus: published.

201 tests pass across tests/core and tests/application/publish; the new tests fail if the constant is reverted.

Worth a separate look

continue on a failed staged artifact means an artifact the operator explicitly asked to publish is dropped inside a run that reports success — the same shape as P0-39. Raising, or at least a non-zero exit, seems more honest. Not changed here.