feat(generator): two-hop name resolution for sub-resource commands

[neilmartin83]

Summary

Sub-resource commands with composite paths (e.g. /v1/enrollment-customization/{id}/all/{panel-id}) cannot support get-by-name, delete-by-name, or apply because the list path contains an unresolved parent path parameter. The generator currently skips these commands (as of #103).

Affected resources

Resource	List path	Parent param	Parent resource
enrollment-customization-panels	/v1/enrollment-customization/{id}/all	{id}	enrollment-customizations
patch-policy-logs	/v2/patch-policies/{id}/logs	{id}	patch-policies
ddm-statuss	/v1/ddm/{clientManagementId}/status-items	{clientManagementId}	device lookup

Of these, only enrollment-customization-panels is a natural fit for name-based resolution (the others are status/log resources keyed by device or policy ID).

Proposed approach

1. Detect unresolved {param} in the derived list path during generation
2. Resolve which parent resource owns that param by matching the path prefix to another spec's collection path (e.g. /v1/enrollment-customization/{id}/all → /v2/enrollment-customizations)
3. Generate a --parent <name> flag on get-by-name / delete-by-name / apply that resolves the parent name → ID first, then substitutes it into the list path before performing the actual name resolution

Alternatives

• Handwritten command: For just enrollment-customization-panels, a hand-coded command in pro_enrollment_customization_panels.go may be simpler than adding cross-resource resolution to the generator.
• Positional arg: Use get-by-name <parent-name> <panel-name> instead of a flag. Consistent with how get <id> <panel-id> already works for multi-param commands.

Context

Filed from #103 which added hasResolvableID to skip generating broken name-resolution commands for these resources. This issue tracks adding the capability back via proper two-hop resolution.