[Bug]: `patch-envelope` lint rule is stricter than ARM RPC guidance for `sku` and `identity`

[FumingZhang]

Describe the bug

Problem

The patch-envelope rule requires all envelope properties (identity, managedBy, plan, sku, tags) to be present in the PATCH body if they exist on the resource. This is stricter than the ARM RPC spec:

Property	ARM RPC Rule	Requirement
tags	RPC-Patch-V1-03	must
sku	RPC-Patch-V1-09	may
identity	RPC-Patch-V1-11	may

Resources that legitimately don't support updating sku or identity via PATCH (permitted by the spec) are incorrectly flagged.

Current Behavior

The rule reports:

The Resource PATCH request for resource 'MyResource' is missing envelope properties: [identity, sku]. Since these properties are supported in the resource, they must also be updatable via PATCH.

The "must" language contradicts the spec's "may" for sku/identity.

Expected Behavior

Differentiate by requirement level:

• tags: Keep the warning (required per RPC).
• sku, identity: Either don't flag, or use a lower severity (hint/info), since the spec says "may".

References

• Rule: packages/typespec-azure-resource-manager/src/rules/patch-envelope-properties.ts

Reproduction

https://github.com/Azure/azure-rest-api-specs/blob/116779f2a6b5a8858dc3881b2e06a8b4b811cad9/specification/containerservice/resource-manager/Microsoft.ContainerService/aks/CommonModels.tsp#L3930C1-L3931C19

Checklist

• Follow our Code of Conduct
• Check that this issue is about the Azure libraries for typespec. For bug in the typespec language or core libraries file it in the TypeSpec repo
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[markcowl]

Note that linting rules in typespec are meant to specify best practices, not merely requirements, because they show up during spec authoring and are suppressible. Note that, if we ever do elevate some rules to lintdiff-level suppressions, then it would be appropriate to differentiate between requirements and best practices. But, for new APIs, we actually want people to use the best practice unless there is a very good reason not to do so.

Will keep this open on the backlog, to track the need for this change when we implement a different level of suppression