ARM API Reviewer agent: verify dropped readme.md / suppressions.yaml entries against the emitted OpenAPI, not the TypeSpec source #43651

Background

When a PR drops a suppression (an entry present in the previous version's readme.md or suppressions.yaml is absent in the new version), the natural inference is "the author fixed the underlying violation." That inference is wrong more often than expected:

• Suppression removal is a structural diff signal, not evidence of a fix.
• The lint rule that the suppression silenced runs on emitted swagger, not on the TypeSpec source. A perfectly correct source-level decorator (@visibility(Lifecycle.Read), @readOnly) can still produce a non-compliant emitted shape due to emitter behavior or $ref-interaction patterns.

Several high-frequency rules fire on a specific emitted shape that is independent of the source decorator. For example, ProvisioningStateMustBeReadOnly triggers on { "$ref": "...", "readOnly": true }. Per JSON Schema, siblings of $ref are ignored, so the readOnly is silently dropped at validation time even though the TypeSpec source looks correct.

Proposal

For every dropped suppression, the Reviewer records a violation-absence anchor in the Step 6 internal artifact (same shape as the THANK-AND-RESOLVE proof-of-fix anchor): rule ID + emitted-OpenAPI jsonpath checked + line number at session SHA + one-line description of the shape now present. A dropped suppression without a recorded anchor is a Step 4 omission and blocks the Step 6 report.

Verification is against the emitted OpenAPI, not the TypeSpec source. For high-frequency rules, maintain an anti-pattern lookup table:

• ProvisioningStateMustBeReadOnly: grep emitted JSON for "provisioningState" and confirm the value is not an object containing both $ref and a sibling readOnly: true.
• LroPostMustNotUseOriginalUriAsFinalState: grep for x-ms-long-running-operation: true on POST and confirm x-ms-long-running-operation-options.final-state-via is present and is not original-uri.
• XmsPageableMustHaveCorrespondingResponse: grep for x-ms-pageable and confirm the response schema contains the nextLinkName field.

If the emitted shape still violates the rule, the dropped-suppression case is a Blocking finding (not a Warning). The PR will fail CI and the fix is non-trivial.

References

• arm-api-reviewer.agent.md, Step 4 "For readme.md suppression files"
• .github/skills/azure-api-review/references/suppression-review-criteria.md

Acceptance criteria

• Anti-pattern table grows as new high-frequency rules are identified.
• Evals cover the $ref-sibling false-positive case (suppression dropped, source looks correct, emitted shape still violates).
• No suppression-removal is silently accepted as evidence of a fix.