Add DenyAssignment TypeSpec with 2024-07-01-preview CreateOrUpdate/Delete operations

[jruttle]

Summary

Adds TypeSpec definitions for the DenyAssignment sub-service under Microsoft.Authorization, covering:

• Stable 2022-04-01: Read-only operations (Get, List, ListForScope, ListForResourceGroup, ListForResource, GetById)
• Preview 2024-07-01-preview: Adds CreateOrUpdate and Delete operations, plus the DenyAssignmentEffect enum

Context

This is a focused TypeSpec addition for DenyAssignment operations. The corresponding Swagger spec was merged in PR #41104.

A broader Authorization TypeSpec migration is in progress in PR #41617 (wave 6 batch), but that PR has CI failures across all checks and may take time to resolve. This smaller, focused PR enables SDK generation for the deny assignment create/delete feature while the full migration progresses.

Changes

• DenyAssignment.Management/main.tsp — Namespace definition with API versions (2022-04-01, 2024-07-01-preview)
• DenyAssignment.Management/DenyAssignment.tsp — All 8 operations (6 read + CreateOrUpdate + Delete)
• DenyAssignment.Management/models.tsp — DenyAssignmentProperties, DenyAssignmentPermission, DenyAssignmentEffect enum
• DenyAssignment.Management/back-compatible.tsp — Flatten property compatibility
• DenyAssignment.Management/tspconfig.yaml — Autorest emitter configuration
• DenyAssignment.Management/examples/ — Example files for both API versions
• Common/main.tsp — Shared types (Principal, PrincipalType, CloudError)
• Regenerated swagger for stable/2022-04-01 and preview/2024-07-01-preview from TypeSpec

Validation

• TypeSpec compiles cleanly with zero errors (1 expected warning for operationId override)
• Generated Swagger matches the existing hand-written spec (all 8 operations, correct response codes, matching operationIds)

Related

• Swagger spec PR: Add PUT/DELETE operations for Microsoft.Authorization denyAssignments (2024-07-01-preview) #41104 (merged)
• Full Authorization TypeSpec migration: [TSP Migration][authorization-12-01]TypeSpec migrated from swagger #41617 (in progress)
• SDK PRs blocked on TypeSpec: Python, Go, JS, .NET, Java
• CLI PR: azure-cli#33109 (blocked on Python SDK)
• PowerShell PR: azure-powershell#29340 (independent, all CI green)

[github-actions]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR targets either the main branch of the public specs repo or the RPSaaSMaster branch of the private specs repo. These branches are not intended for iterative development. Therefore, you must acknowledge you understand that after this PR is merged, the APIs are considered shipped to Azure customers. Any further attempts at in-place modifications to the APIs will be subject to Azure's versioning and breaking change policies. Additionally, for control plane APIs, you must acknowledge that you are following all the best practices documented by ARM at aka.ms/armapibestpractices. If you do intend to release the APIs to your customers by merging this PR, add the PublishToCustomers label to your PR in acknowledgement of the above. Otherwise, retarget this PR onto a feature branch, i.e. with prefix release- (see aka.ms/azsdk/api-versions#release--branches).
• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR is awaiting ARM reviewer feedback (label: WaitForARMFeedback).
  To learn when this PR will get reviewed, see ARM review queue at aka.ms/azsdk/pr-arm-review
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ The required check named Swagger LintDiff has failed. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide

Comment generated by summarize-checks workflow run.

[jruttle]

Label Justifications

\Approved-Avocado\

The \MULTIPLE_API_VERSION\ error is a pre-existing condition in the Authorization service readme. The default tag \package-2025-12-01-preview\ intentionally aggregates swagger files from multiple API versions (2015-07-01, 2022-04-01, 2024-07-01-preview, etc.) — this is the established pattern for this large RP. Our change adds the new \preview/2024-07-01-preview/authorization-DenyAssignmentCalls.json\ to this existing tag structure.

\BreakingChange-Approved-Benign\

The cross-version breaking changes detected are expected artifacts of the TypeSpec conversion:

• AddedPath: New PUT/DELETE operations for deny assignments (additive — new preview API version)
• DifferentStructure (1032): TypeSpec generates parameters inline vs \ — functionally equivalent
• AddedRequiredProperty (1034): \�alue\ property on list response — standard ARM list pattern
• RemovedClientParameter (1007): Parameters like \ScopeParameter, \FilterParameter\ etc. are now inline per TypeSpec conventions rather than top-level \ parameters — functionally identical

All changes are benign structural differences from the TypeSpec conversion, not breaking API behavior changes.

[pshao25]

Under TypeSpec conversion. Please hold on.

[jruttle]

Closing this PR — we've confirmed that a DenyAssignment-only TypeSpec can't produce a viable SDK. The Authorization SDK ships as a monolithic package (azure-mgmt-authorization) covering RoleAssignments, RoleDefinitions, DenyAssignments, Permissions, etc. A partial TypeSpec generates an incomplete package that can't be published.

The correct path is PR #41617 (full Authorization TypeSpec conversion by @pshao25). We're coordinating directly with Pan Shao's team to help unblock that effort.

This PR's learnings (folder structure, SDK emitter configs, example operationId requirements, label bypasses) are documented and will be useful when contributing to #41617.