[rdimitrov]

Summary

gopkg.in/yaml.v3 is no longer maintained, and it panics with hash of unhashable type map[string]interface {} when a mapping has a << merge key next to a key that is itself a mapping (OSS-Fuzz testcase 4870994700075008). One of the inputs that can trigger this comes from the network: the registry /openapi.yaml check parses whatever a remote registry sends back. The maintained fork go.yaml.in/yaml/v3 (v3.0.5) returns an error for the same input instead of panicking.

• Every remaining importer of gopkg.in/yaml.v3 now imports go.yaml.in/yaml/v3, test files included. go.yaml.in/yaml/v3 becomes a direct dependency.
• Packages that define or decode types with UnmarshalYAML(*yaml.Node) move together. Today that is pkg/json.Data, decoded by the vmcp loader, vmcp serve/init, and the operator vmcpconfig controller. This matters because the custom unmarshaler only fires when the decoder comes from the same library as the yaml.Node type.
• Adds TestClient_ValidateEndpoint in pkg/registry/api, which includes the crash input ? {a: b}\n: c\n<<: {name: x}\n and expects an error.

This pairs with #6919, which moves pkg/skills. Once both are merged, gopkg.in/yaml.v3 is no longer a direct dependency and can be dropped from the direct requirements in go.mod.

Type of change

• Bug fix

Test plan

• Unit tests (task test)
• Linting (task lint-fix)

Lint ran with the CI-pinned golangci-lint v2.15.0 via go run on the touched packages, because local task lint-fix is broken on Go 1.27. I also checked by hand that the crash input panics gopkg.in/yaml.v3 and returns an error from go.yaml.in/yaml/v3, both for map[string]interface{} and for interface{} targets.

Does this introduce a user-facing change?

Before: a YAML document (a config file, vmcp config, client config, or a registry's /openapi.yaml) that combined a merge key with a mapping-valued key crashed thv, vmcp, or the operator with a panic. After: the same input is rejected with a parse error.

Special notes for reviewers

• This PR goes over the 10-file limit: 13 non-test files plus go.mod, about 40 changed lines. Each change is the same mechanical import-path swap, and keeping them in one PR was approved deliberately. Splitting along package lines would have to keep the pkg/json + vmcp group together anyway, for the yaml.Node reason above.
• pkg/skills/{parser,types,parser_test}.go still import gopkg.in/yaml.v3 on purpose. Parse SKILL.md with maintained YAML fork #6919 covers them.
• The fork also hits the same "unhashable map key" runtime error internally, but it catches it and returns it as an ordinary yaml: runtime error: ... error, so the new test only asserts that an error comes back.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.83%. Comparing base (aed6a97) to head (13a1c38).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6920      +/-   ##
==========================================
+ Coverage   79.79%   79.83%   +0.03%     
==========================================
  Files         828      828              
  Lines       84632    84632              
==========================================
+ Hits        67531    67564      +33     
+ Misses      17096    17063      -33     
  Partials        5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.