docs: Add reference documentation for Microsoft.Windows/FirewallRuleList

[Gijsreyn]

PR Summary

This pull request adds reference documentation for the built-in DSC resource Microsoft.Windows/FirewallRuleList.

[Copilot]

Pull request overview

Adds reference documentation and examples for the built-in DSC resource Microsoft.Windows/FirewallRuleList, describing its schema, capabilities, and common usage patterns for getting/setting/exporting Windows Firewall rules.

Changes:

• Added a full resource reference page including properties, schema, exit codes, and links to examples.
• Added a “get/toggle/export” CLI example page for dsc resource usage.
• Added a configuration-document example (YAML) plus a walkthrough for dsc config test/set and rule removal.

Reviewed changes

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

File	Description
docs/reference/resources/Microsoft/Windows/FirewallRuleList/index.md	New reference page for the resource (syntax, properties, schema, exit codes, links).
docs/reference/resources/Microsoft/Windows/FirewallRuleList/examples/get-firewall-rules.md	New CLI-oriented example for get/set/export behavior.
docs/reference/resources/Microsoft/Windows/FirewallRuleList/examples/firewall.config.dsc.yaml	New sample DSC config document defining two firewall rules.
docs/reference/resources/Microsoft/Windows/FirewallRuleList/examples/configure-firewall-rules.md	New walkthrough demonstrating config test/set and rule removal.

[Gijsreyn]

@SteveL-MSFT - one of the remarks from Copilot was the min/max on the protocol property. Even though, when running it, for example, with 257, the executable throws a useful error message. However, I have updated the resource manifest to include both minimum and maximum, as I do think it adds value for authoring-time feedback and fails early without spawning a process.

If not, let me know, and I'll remove it from the docs.

[michaeltlombardi]

Out of scope for this PR, but we should consider altering this behavior for the next release.

_exist is a canonical property with strong contracts. We shouldn't have any resources that implement a canonical property in a surprising way that requires callouts like this.

It's always an optional field to send to the resource, because the default is true, but we should always return the fully defined actual state of the resource, including _exist as either true or false.

[SteveL-MSFT]

Canonical _exist defaults to true so it should be canonical that absence means it exists

[michaeltlombardi]

Correct, and that's particularly ergonomic from an input-data perspective - but from a result reading perspective, omitting fields to imply their default value is at best confusing.

In this case, we're saving a line in the output YAML at the cost of clarity/explicitness.

For a reader to understand why some results have _exist: false and others omit _exist, the reader needs to either have familiarity either with the canonical property schema contract (and JSON Schema behavior) or have read the documentation.

I think this is a case where not having a resource-authoring guide / checklist leads us to differing implementations. In general, a resource should imo always return the fully explicit data for an instance to reduce the need for dereferencing/contextualizing a result in combination with its JSON Schema.

For canonical properties this is arguably less of a concern, but if a resource defines the optional foo property with a default of bar and doesn't return foo in the output data, should we interpret the instance as having foo set to bar? Can we infer that without looking at the JSON Schema from a higher order tool or uninformed user perspective?

[SteveL-MSFT]

@michaeltlombardi I think we should have a separate discussion on best practices for defaults. We have the same problem for sshd_config and that resource is working towards a particular implementation, but we should discuss it at the WG level on how we want all resources to do that.

[michaeltlombardi]

Approved for editing pass, ready for final technical review.