Support 'resource-type' as a valid OCI repo artifact type

[chrisghill]

Wires the RESOURCE_TYPE artifact type (added in massdriver-sdk-go v0.2.11) through the mass repository commands, which previously assumed bundles were the only artifact type.

Changes

• SDK bump to v0.2.11, which exposes ArtifactTypeResourceType.
• --type resource-type now resolves on mass repository create and mass repository list --type.
• Output rendering — resource-type repos now render with the friendly resource-type label in list and get output instead of the raw RESOURCE_TYPE enum.
• Help & error text — flag help now reads (bundle, resource-type), and the "unknown artifact type" error enumerates valid types in a deterministic (sorted) order via a single shared helper (previously duplicated with nondeterministic ordering).

Refactor

• Extracted the artifact-type resolution/label logic out of cmd/repository.go into a new internal/commands/repository package (ResolveArtifactType, ArtifactTypeLabel, ValidArtifactTypes), matching the convention where cmd/ only wires cobra and testable logic lives under internal/commands.

Tests

• Added internal/commands/repository/artifacttype_test.go covering alias↔enum round-tripping for both types, case-insensitive resolution, the sorted unknown-type error message, and the raw-string label fallback for unmapped enums.

Notes

• mass bundle create is unaffected — it hardcodes ArtifactTypeBundle and shares the same create path.

[chrisghill]

@claude review

[claude]

Claude finished @chrisghill's task in 1m 37s —— View job

---

Review complete

• Gather context (PR diff, changed files)
• Review internal/commands/repository/artifacttype.go (new resolution/label logic)
• Review cmd/repository.go changes
• Review tests in artifacttype_test.go
• Check go.mod/go.sum bump and docs regen

Overall this is a clean, well-scoped change. The refactor genuinely improves the code (single source of truth for alias↔enum mapping, deterministic sorted error output, better cmd/-vs-internal/commands separation), and the new tests cover the interesting behaviors (round-trip, case-insensitivity, sorted error text, raw-enum fallback).

Findings:

1. Nit — stale doc comment for shared behavior (internal/commands/repository/artifacttype.go:10-14): The comment on artifactTypeAliases says "maps the user-facing --type flag values" — accurate — but consider a one-line note that mass bundle create (cmd/bundle.go:209) also funnels through ResolveArtifactType via createOciRepoCommon, since a future reader modifying this map might not realize bundle creation depends on the "bundle" key resolving via strings.ToLower(string(ocirepos.ArtifactTypeBundle)). Not a bug — just a subtle coupling worth a comment given it isn't obvious from either file alone.

2. Verify the SDK bump compiles clean — I wasn't able to run go build ./... or go test ./... in this sandbox (tool approval for go commands wasn't available in this automated context), so I could not confirm ocirepos.ArtifactTypeResourceType exists as described in massdriver-sdk-go v0.2.11, or that the full test suite passes. Everything reads correctly against the PR description and existing usage patterns, but please confirm CI is green before merging. If you'd like me to verify this myself, granting Bash(go build:*)/Bash(go test:*) in --allowedTools would let me do it directly next time.

Confirmed correct:

• strings and fmt imports remain used in cmd/repository.go after the extraction (no dead imports).
• No other references to the removed resolveArtifactType/artifactTypeLabel/artifactTypeAliases/artifactTypeLabels symbols remain anywhere in the repo.
• No existing tests for cmd/repository.go/cmd/bundle.go depended on the removed private functions.
• mass bundle create is untouched functionally — still hardcodes ArtifactTypeBundle through the same shared createOciRepoCommon path, as called out in the PR notes.
• Docs regeneration (docs/generated/mass*.md) is consistent with the new flag help text and command short descriptions.
• Error message construction (unknown artifact type %q (valid: %s)) is now defined in exactly one place and used consistently by both list --type and create --type.

No blocking issues found — nice, focused refactor alongside the feature addition.