feat(scanner): compute rule quality pass — subnet NSGs, Defender health, real patch state #268

What problem does this solve?

Three existing compute rules each rely on a weak signal that produces false positives or false
negatives, found by reading the current rule files directly:

• AZ-CMP-001 (scanner/rules/az_cmp_001.py) only checks NIC-level NSGs, never subnet-level. A VM
  protected only by a subnet-level NSG (a common, valid pattern) is a false-positive HIGH finding
  today.
• AZ-CMP-003 (scanner/rules/az_cmp_003.py) only checks whether a known extension name is
  installed, with no health/status check. An installed-but-unhealthy AV/EDR agent still reads as
  "protected."
• AZ-CMP-004 (scanner/rules/az_cmp_004.py) only reads enable_automatic_updates/patch_mode config
  flags, never actual patch compliance. A VM can look compliant by config and still be months
  behind on real patches.

Describe the solution

• AZ-CMP-001: resolve the subnet for each NIC's IP configuration and check for a subnet-level NSG
  in addition to the existing NIC-level check; only flag when neither has one. Test matrix:
  NIC-only, subnet-only, neither, both.
• AZ-CMP-003: query Microsoft Defender for Cloud health/status for the VM instead of (or as a
  fallback, with reduced confidence, alongside) extension-name presence.
• AZ-CMP-004: query actual patch assessment data (Azure Update Manager /
  Microsoft.Maintenance assessment results) and factor real patch state into the finding, keeping
  the config-flag check as a fallback signal.
• These can land as one PR since they're the same shape of fix (replace a weak signal with a
  stronger one) in the same rule domain.

Alternatives considered

Leave each as-is until someone hits the false positive/negative in production — rejected; all
three are already confirmed wrong by direct code inspection.

Additional context

Confirmed against current code at time of filing — re-verify against HEAD before starting work in
case any of these three has since been touched.