Defender CSPM vulnerability assessment stuck — firstEvaluationDate == statusChangeDate unchanged for 18+ days despite fix deployed

Summary

Three Defender for Cloud recommendations — "Update next", "Update postcss", "Update @babel/runtime" — on a single Azure Web App have been Unhealthy since the day Defender CSPM was first enabled, even though the vulnerabilities were remediated and deployed 4 days later. The assessment data appears frozen at the initial onboarding scan and has not re-evaluated in 18+ days.

Environment

• Azure Web App (Linux, Node 22), Next.js app; deployed via GitHub Actions (azure/webapps-deploy, WEBSITE_RUN_FROM_PACKAGE=1)
• Defender CSPM (CloudPosture): Standard, enabled 2026-06-08T03:33Z (free trial)
• Defender for App Service: Standard
• Recommendations surface under the attack path "Internet exposed Azure Web App with high severity vulnerabilities"

The problem

All three Update <package> assessments show:

• status.code = Unhealthy
• firstEvaluationDate == statusChangeDate == 2026-06-08T04:18:37Z (identical — ~45 min after CSPM was enabled, i.e. the onboarding scan)
• No status change in 18+ days

The recommendation detail blade shows Freshness: 24 Hours and Last change date: 6/8/2026.

What I've already verified (to rule out the usual causes)

1. The fix is deployed. next upgraded 14→16, postcss pinned via overrides, and @babel/runtime is no longer in the dependency tree at all — confirmed in the committed package-lock.json and the deployed artifact. App redeployed successfully several times since (latest 2026-06-24); main HEAD == last deployment.
2. It is not an Azure Policy issue. az policy state list --resource <resource-id> shows these three recommendations are not policy-backed — they never appear in the resource's policy compliance state. The only non-compliant policies are unrelated config items, and they evaluated freshly on 2026-06-25. So the Policy evaluation engine is current; only the vulnerability-assessment layer is stale.
3. Via Resource Graph (securityresources), the three findings exist only as microsoft.security/assessments with the frozen firstEvaluationDate == statusChangeDate above.
4. The feeding plan extensions are enabled (AgentlessVmScanning etc. = True).

Questions

1. What triggers a re-scan of the App Service code/dependency vulnerability assessment, and is there any supported way to force one? (Redeploy and restart did not refresh it; az policy state trigger-scan is not applicable since these aren't policy-backed.)
2. What is the expected refresh cadence for this assessment type? A firstEvaluationDate == statusChangeDate that never updates for 18+ days suggests the assessment simply isn't re-running for this resource.
3. Is this a known aggregation / VA pipeline stall that requires server-side intervention? If so, what is the path to resolution?

Happy to provide the subscription ID and resource ID privately. Thanks!