fix: Use specific exception types in ArmClientExtensions

[thomhurst]

Summary

• Creates AzureResourceNotFoundException (inherits InvalidOperationException) for when resources cannot be found
• Creates UnsupportedAzureScopeException (inherits NotSupportedException) for unsupported scope types
• Replaces generic throw new Exception(...) with these specific exceptions
• Adds XML documentation explaining when each exception is thrown

Note: Issue #1574 (SuccessHttpHandler) was already fixed in a previous commit that removed the class entirely.

Fixes #1578

Test plan

• Build passes

🤖 Generated with Claude Code

[thomhurst]

Summary

Replaces generic exceptions with custom typed exceptions for Azure resource operations.

Critical Issues

None found ✅

Suggestions

Exception Constructor Consistency

Both new exception classes follow good practices with proper constructors accepting innerException. However, consider if serialization support is needed (though unlikely for ModularPipelines use case).

Error Message Quality

In UnsupportedAzureScopeException:20, the error message includes both the type name AND the scope value. Since AzureScope is a record, the ToString() output might be redundant with the type name. Consider if this provides useful information or just noise.

Example output would be:
Unsupported Azure scope type: AzureManagementGroupIdentifier.
Scope value: AzureManagementGroupIdentifier { Name = "test" }

If the scope value is useful for debugging, this is fine. If not, you could simplify to just the type name.

XML Documentation Completeness

The XML documentation is well-written. The exceptions are properly marked with tags in the extension method's XML doc, which is excellent for API consumers.

Previous Review Status

Cannot access previous comments due to GitHub token scope limitations.

Verdict

✅ APPROVE - No critical issues

The PR improves exception handling by replacing generic exceptions with strongly-typed, semantically meaningful exceptions. This makes it easier for consumers to catch and handle specific error scenarios. The implementation follows standard exception patterns with proper inheritance (InvalidOperationException for "not found", NotSupportedException for "unsupported scope") and includes well-documented constructors.