[HAR] harness execute registry:migrate — parity gaps and bugs vs hc

Summary

Comparison of harness execute registry:migrate against the hc CLI revealed the following bugs and missing features:

Bugs

1. Failed artifacts don't fail the run
If one or more artifacts fail to migrate, the command still exits 0 and prints "Migration completed successfully." Automation and CI pipelines will treat a partial migration as a success.

2. packageFilters silently dropped
hc supports a packageFilters config field to migrate only specific packages, this command uses includePatterns/excludePatterns instead. So a customer who pastes their working hc config expecting a filtered migration will silently get the entire registry migrated instead as YAML parsers silently ignore that field.

3. Unknown artifactType not rejected at config load
hc rejects unknown/mistyped artifact types immediately at config load before making any network calls. harness silently accepts them, contacts both source and destination registries, then fails mid-run with "get packages failed: unknown artifact type" — still printing "Migration completed successfully." and exiting 0.
Verified: artifactType: generic (lowercase)

• harness — hits both registries, fails mid-run, empty stats table, exits 0
• hc — fails at load: unknown artifactType "generic" — valid values are: DOCKER, HELM, ..., exits 1

Missing features

4. Missing artifact types — CRAN, RUBY, TERRAFORM are supported by hc but not by this command. These are not just missing from the type list — the CLI accepts them silently, makes live network calls to both registries, then fails mid-run with "unknown artifact type", exits 0, and prints "Migration completed successfully." with nothing migrated.

5. --result-file — hc writes one JSON-lines record per artifact so automation can inspect exact outcomes even on failure. No equivalent here.

6. --summary flag — to suppress/control the final stats table output.

7. Missing artifact types — CRAN, RUBY, TERRAFORM are supported by hc but not by this command.

8. No skip reason — when an artifact is skipped, there's no indication of why (already exists, nothing to migrate, etc.).

9. Config file not documented in help — hc ships example configs. New users have no idea what the config file should look like.

Note: Bugs 3 and 4 share the same root cause — validateConfig in modules/har/pkg/har/migrate/types/config.go has no IsKnownArtifactType() check

Start with the harness execute registry:migrate entry point and read modules/har/pkg/har/migrate/types/config.go, especially validateConfig and the missing IsKnownArtifactType() check. Compare its behavior with the hc CLI for failed artifacts, packageFilters, artifact types, result files, summaries, skip reasons, and config help. Done means the listed parity gaps are addressed and invalid configurations fail before network calls.