[deckhouse-cli] New plugins contract support - impl [2/2]

[Glitchy-Sheep]

Summary

This PR implements support for the new plugin contract format:

• New cluster-side requirements (Kubernetes / Deckhouse) with version constraints
• Module dependencies have three flavours:
  • mandatory
  • conditional
  • anyOf
• Friendlier error messages when a contract is malformed
• Cluster-side checks themselves are log-only stubs - declared constraints are reported to the operator but not yet enforced against a live cluster

The refactor stage (PR [1/2]) is the base of this branch and must be merged first.

---

⭐ What the new contract format enables

• Deckhouse version constraints - new top-level deckhouse field for declaring "this plugin needs Deckhouse >= 1.65".
• Conditional dependencies:
  • mandatory for "always required"
  • conditional for "only enforced if the dependency is actually installed". Useful when a plugin wants to say "if module X is enabled, I need at least v2.40 of it" without forcing X to be present.
  • anyOf you need at least one of N modules (e.g. some ingress controller, doesn't matter which).

---

🐛 Alongside the format change, this PR also fixes one latent bug that existed in v1 and would have carried over:

• Conflict detection - the reverse-conflict check compared installedPlugin.Version against itself, which was tautologically true, so real conflicts were silently accepted. Now compares against the new plugin's version.

---

📄 Contract shape: before vs after

---

▶️ Example Flow with new Contracts

---

🚶‍♂️‍➡️ Implementation walkthrough

1. Structured Requirements DTO.

   • Typed Kubernetes, Deckhouse, ModuleRequirementsGroupDTO, PluginRequirementsGroupDTO replace the flat arrays.
   • ContractToDomain / DomainToContract factored into 6 small per-field helpers.

2. Validator split + conflict-check fix.

   • mandatory is soft (resolvable with --resolve); conditional is a hard error only when the dependency is actually installed.
   • Conflict check now compares against the new plugin's version (was tautologically self-comparing), and walks both .Mandatory and .Conditional of every installed plugin.

3. Cluster-side requirements as log-only notices.

   • validateKubernetesRequirement / validateDeckhouseRequirement / validateModuleRequirement parse the constraints and print a two-line stderr record:

   !  plugin declares a Deckhouse version requirement but enforcement is not implemented yet
         plugin: package
         constraint: >= 1.65
   

   Real cluster connectivity (kubeconfig + clientset + module discovery) is out of scope - lands in a follow-up PR.

4. Friendlier error messages.

   • New unmarshalContract helper rewrites encoding/json errors as user-actionable messages, shared by the registry-annotation and local-file paths:

   Before:

   Error: failed to unmarshal contract: json: cannot unmarshal array into Go struct field PluginContract.requirements.modules of type service.ModuleRequirementsGroupDTO
   

   After:

   Error: invalid contract: field "requirements.modules" must be an object with mandatory/conditional sections, got a JSON array
   

Verification

• go build ./... clean at every commit.
• Unit tests cover the v2 contract round-trip, the validatePluginConflict regression suite (bug regression, happy path, conditional detection), and the invalid-contract error paths.

Follow-up

Real cluster-side enforcement (kubeconfig + clientset + module discovery against a live API server) is intentionally out of scope. The contract surface, validation skeleton, and operator-facing notices land in this PR; runtime enforcement lands later.