Fix: Dynamically extract resourceType to prevent 400 Bad Request error

[0xharkirat]

Problem

The current implementation hardcodes "resourceType": "AzureSolutionTemplatePackageConfiguration" in the application_generateUpdatePackageReferenceRequestBody() function. This causes a 400 Bad Request error when the package configuration uses a different resource type (e.g., AzureApplicationPackageConfiguration).

Error Details

When running the workflow, the API returns:

400 Bad Request: The resourceType in the request body doesn't match the actual resource type

Solution

This PR modifies the application_generateUpdatePackageReferenceRequestBody() function to:

1. Dynamically extract the resourceType from the existing $configuration variable (which contains the current package configuration)
2. Use jq to preserve the original resourceType and id fields while updating only the version and packageReferences

Changes Made

• Replaced the hardcoded JSON template with a dynamic jq transformation
• The resourceType and id are now preserved from the existing configuration
• Only version and packageReferences are updated with new values

Before

cat <<EOF
{
    "resourceType": "AzureSolutionTemplatePackageConfiguration",  # ❌ Hardcoded
    "version": "${artifactVersion}",
    "packageReferences": [...]
}
EOF

After

echo "$configuration" | jq --arg v "$artifactVersion" --arg pkg "$packageId" '
  .version = $v
  | .packageReferences = [
      {
        "type": "AzureApplicationPackage",
        "value": $pkg
      }
    ]
'

Benefits

• ✅ Works with any resourceType (e.g., AzureSolutionTemplatePackageConfiguration, AzureApplicationPackageConfiguration)
• ✅ Preserves all existing configuration fields
• ✅ Prevents 400 errors due to resource type mismatch
• ✅ More maintainable and flexible

Testing

Tested with workflows that use different resource types and confirmed the 400 error is resolved.