Support array for Microsoft.Windows/Registry resource

[Gijsreyn]

PR Summary

The Microsoft.Windows/Registry resource now accepts a registryKeys array wrapper (mirroring the Microsoft.Windows/UpdateList pattern), so a single invocation can manage multiple registry entries.

Shouldn't be a breaking change as both input shapes are supported

PR Context

[Copilot]

Pull request overview

This PR extends the Microsoft.Windows/Registry resource’s config input schema to support a registryKeys array wrapper (similar to the Microsoft.Windows/UpdateList pattern), enabling a single invocation to manage multiple registry keys/values while still supporting the existing single-item input shape.

Changes:

• Introduced RegistryKey / RegistryList types and an untagged Registry input enum to support both single and wrapper shapes.
• Updated the Registry resource CLI (registry config get|set|delete) to parse and process multiple items.
• Added Pester coverage for multi-item get/set/delete/what-if flows, and updated dependent code (sshdconfig) for renamed types.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
resources/sshdconfig/src/get.rs	Updates registry helper output type usage from Registry to RegistryKey.
resources/registry/src/main.rs	Adds wrapper parsing/emission and loops operations over multiple registry items.
lib/dsc-lib-registry/src/lib.rs	Refactors helper to operate on RegistryKey and adds new_from_key.
lib/dsc-lib-registry/src/config.rs	Introduces RegistryKey, RegistryList, and untagged Registry to support both input shapes.
resources/registry/tests/registry.config.whatif.tests.ps1	Adds what-if coverage for multi-item wrapper input.
resources/registry/tests/registry.config.set.tests.ps1	Adds set/delete coverage for multi-item wrapper input and cleanup.
resources/registry/tests/registry.config.get.tests.ps1	Adds get coverage for multi-item wrapper input and missing-item behavior.

[michaeltlombardi]

I think, if we support this at all, it should be as a separate resource - Microsoft.Windows/RegistryList or similar.

There are significant drawbacks to the list-form for resources in terms of output readability and referencing. In general, I think we should consider limiting list-form resources to those where the implementation has significant overhead that makes serial invocations noticeably slower than passing the array to the resource. The list-form will generally always be some improvement in performance but for many resources the improvement may not be worth the degraded readability.

List resources are also more difficult to represent in the node graph - specifically more difficult than a group resource, which expands into a node with several children.

Finally, I worry that this further complicates an already complex-to-reason-about JSON Schema.

[Gijsreyn]

Thanks @michaeltlombardi - those are fair points, and without a doubt, I couldn't disagree. I had thought of the schema, but not about the others.

I'll revert or abandon this PR and open a follow-up issue to discuss whether Microsoft.Windows/RegistryList is worth introducing.

Happy to see some data showing serial calls are actually a bottleneck.

[Gijsreyn]

Closed as superseded on: #1514