fix(scanner): remove compute-rule false positives/negatives (#268)

[parthrohit22]

Summary

Issue #268 claimed three compute rules relied on weak signals that produce false positives or
false negatives. Read the current code first (per the issue's own instruction to verify rather
than assume) and confirmed two of the three claims, fixed both, and found the third already
resolved.

Root cause per rule

• AZ-CMP-001 (scanner/rules/az_cmp_001.py): only checked nic.network_security_group.
  A VM whose NIC had no NSG of its own but whose subnet carried one -- a common, valid Azure
  pattern -- was flagged as a false-positive HIGH finding.
• AZ-CMP-003 (scanner/rules/az_cmp_003.py): only checked whether a recognised
  endpoint-protection extension name was present (KNOWN_EP_EXTENSIONS), with no health check.
  An installed-but-failed EP extension read as a silent compliant pass -- a false negative.
• AZ-CMP-004 (scanner/rules/az_cmp_004.py): claimed to use a weak patch signal. Verified
  against current code -- it already checks patch_mode == "AutomaticByPlatform" for both
  Windows and Linux (in addition to the Windows enable_automatic_updates flag). Already
  correct, no change made.

What changed

• Added AzureClient.get_subnet(subnet_id) (scanner/azure_client.py), following the
  get_network_interface/get_disk pattern: parses resource group/vnet/subnet name out of the
  subnet resource ID, returns Optional[Any], logs and returns None on any failure.
• az_cmp_001.scan(): a VM is now non-compliant only when it has a public IP and no NIC-level
  NSG and no subnet-level NSG. An unresolvable subnet is treated as "not protected," never as
  protection, so this only removes false positives -- it introduces no new false negatives.
  Metadata now records nic_nsg_attached / subnet_nsg_attached for transparency.
• az_cmp_003.scan(): when a recognised EP extension is present, its provisioning_state (where
  the API exposes it) is now checked. "Succeeded" or missing/unknown state keeps the existing
  name-based pass (data doesn't support a stricter check, so the bar isn't raised past what's
  confirmable). Any other state (Failed, etc.) now surfaces as an indeterminate LOW finding
  instead of a silent pass, mirroring AZ-CMP-002's existing metadata.determination convention.
  The name-based check remains the primary signal -- a genuinely missing extension still flags
  HIGH exactly as before.
• az_cmp_004.py: unchanged, see above.
• Tests: extended tests/test_rules_compute.py with subnet-NSG-compliant,
  no-NIC-NSG-no-subnet-NSG, and unresolvable-subnet cases for AZ-CMP-001, and
  healthy/unhealthy/no-provisioning-state-data cases for AZ-CMP-003. Added a direct
  AzureClient.get_subnet() unit test to tests/test_azure_client_management.py. Extended
  tests/helpers/mock_azure.py with set_subnet/get_subnet.

Tested

• python -m pytest tests/test_rules_compute.py -q -- 22 passed
• python -m pytest tests/ -q -k "rule or compute" -- 250 passed, 1 skipped (pre-existing skip,
  unrelated)
• ruff check scanner/rules/az_cmp_001.py scanner/rules/az_cmp_003.py scanner/azure_client.py tests/test_rules_compute.py tests/helpers/mock_azure.py tests/test_azure_client_management.py
  -- all checks passed
• No changes to scanner/rules/az_cmp_002.py, identity/enterprise rules, or the frontend.

Fixes #268

[TFT444]

@parthrohit22 Good improvements, but this does not yet complete issue #268. Defender health and real patch-assessment evidence are still missing, and an inaccessible subnet can currently be treated as confirmed unprotected and produce a HIGH finding. Please either implement the remaining scope and return an unknown result for unreadable subnet evidence, or narrow the PR and linked issue to the work actually completed.