Investigate refactoring firewall rule collection rendering to use generic parent-child framework

[oocx]

Context

Feature 068 introduces a generic parent-child framework (ParentChildRelationship, IChildRowExtractor, ChildResourceGroup) for rendering child resources inline as table rows within parent resource sections.

The existing firewall rule collection implementation (Features 026 & 060) solves the same structural problem — parsing inline rule array attributes from azurerm_firewall_network_rule_collection / azurerm_firewall_application_rule_collection and rendering them as table rows — but uses a bespoke approach with typed view models (FirewallNetworkRuleCollectionViewModel, FirewallApplicationRuleCollectionViewModel), typed properties on ResourceChangeModel, and fully custom factories and templates.

Investigation Goals

1. Evaluate feasibility of migrating the firewall rule collection rendering to use the generic parent-child framework introduced in Feature 068.

2. Design IChildCollectionDiffExtractor — a richer interface that accepts both before and after parent state to enable semantic diffing (matching rules by name between before/after states and computing per-rule changes across 6+ columns). The current IChildRowExtractor extracts rows independently and does not support this.

3. Assess the azurerm_firewall → collection relationship — the parent-child catalog documents that azurerm_firewall_network_rule_collection and azurerm_firewall_application_rule_collection are themselves children of azurerm_firewall, but this relationship is not currently handled (each collection renders as its own section). Investigate whether the generic framework can also group collections under their parent firewall.

Current Implementation

• FirewallNetworkRuleCollectionViewModelFactory (~478 lines) — builds typed view models with semantic rule diffing (matching by name, computing per-field diffs)
• FirewallApplicationRuleCollectionViewModelFactory — similar pattern for application rules
• Typed properties on ResourceChangeModel: FirewallNetworkRuleCollection, FirewallApplicationRuleCollection
• Custom Scriban templates: firewall_network_rule_collection.sbn, firewall_application_rule_collection.sbn

Benefits of Migration

• Consistency: All parent-child renderings would use the same framework
• Reduced model coupling: Remove typed view model properties from ResourceChangeModel
• Reuse: The semantic diffing capability (IChildCollectionDiffExtractor) would be available for future resources like NSG rules, route table routes, etc.
• Simpler onboarding: One pattern to learn instead of two

Risks

• The existing implementation works well and has comprehensive tests
• Migration introduces risk of regressions in a stable feature
• The semantic diffing logic is complex and may not fit cleanly into a generic interface

References

• Feature 068 architecture: docs/features/068-parent-child-resource-grouping/architecture.md
• Parent-child resource catalog: docs/features/068-parent-child-resource-grouping/parent-child-resource-catalog.md
• Existing implementation: src/Oocx.TfPlan2Md/Providers/AzureRM/Models/FirewallNetworkRuleCollectionViewModelFactory.cs