[Add Capability]: azure-diagnostics - add VNet peering sync-state check to network troubleshooting

### Existing Skill to Extend

azure-diagnostics

### Contacts

devilfp

### Current Behavior / Gap

`azure-diagnostics` covers general Azure resource troubleshooting (resource health, activity logs, App Insights traces, Application Lens diagnosis) but has no step for checking VNet peering synchronization state. Peering status (`Connected`/`Disconnected`/`Initiated`) is a separate property from Peering sync status (`Fully Synchronized` vs `Remote sync required`). A peering can show Connected on both sides while one side is out of sync — typically after an address-space resize that wasn't followed by a sync operation — and this silently breaks connectivity between the affected address ranges without raising any status-level alarm. Today the skill has no guidance directing the agent to check or resolve this.

### Intended Agent Scenarios

- "Why can't my VM in the spoke reach a resource in the hub VNet?" → agent checks peering status and sync level on both sides, flags RemoteNotInSync, and walks the user through az network vnet peering sync instead of only checking NSGs/UDRs/routes.
- "I resized my hub VNet's address space, now some spokes can't connect" → agent recognizes this as a known peering-desync pattern in hub-spoke topologies and checks sync state across all spoke peerings, not just the one reported.
- General network connectivity troubleshooting flows gain a peering-sync check as a standard step, alongside existing checks like NSG rules and route tables.

### Timeline

TBD — this is a documentation/guidance addition to an existing skill file, not a new capability build, so it could realistically ship in the next skill content update cycle rather than needing a dedicated release.

### Additional Context

- Related skill: `azure-enterprise-infra-planner` designs hub-spoke topologies but doesn't own troubleshooting; `azure-diagnostics` is the correct home for this check.
- No `azure-virtual-network`-specific skill currently exists in the repo — this request assumes the addition lands in `azure-diagnostics` unless maintainers prefer to split networking into its own skill.
- No regional or sovereign-cloud considerations — peering sync behavior is consistent across Azure Public, China, and Government clouds.
- Reference doc: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering

Locate the existing azure-diagnostics skill and read its network troubleshooting guidance, then review the linked Azure VNet peering reference. Add guidance to check peering status and sync state on both sides, recognize RemoteNotInSync after address-space changes, and use az network vnet peering sync; done means the standard connectivity flow covers this scenario.

Written by the indexing model from the issue text.