Fix vPC peering default payload

[dacasti2mx]

Summary

Always render useVirtualPeerlink in roles/dtc/common/templates/ndfc_vpc/ndfc_vpc_peering_pairs.j2, defaulting to false when fabric_peering is omitted from a vpc_peers entry.

Problem

When fabric_peering is not set on a vpc_peers entry, the template currently skips the useVirtualPeerlink field entirely:

{% if vpc_peers_pair.fabric_peering is defined %}
  useVirtualPeerlink: {{ vpc_peers_pair.fabric_peering }}
{% endif %}

Against a freshly-built fabric, the resulting dcnm_vpc_pair call has been observed to receive the pair as input but the artifact does not show a POST for it (the pair is absent from result.diff[0].merged and from result.response). A subsequent dcnm_interface step then fails when it tries to create a vPC port-channel on a peer in that pair:

Create pipeline failed at step 'interface_all' (dcnm_interface):
Switch '<ip>' is not part of VPC pair, but given I/F 'vpc<N>' is of type VPC

Full evidence (artifact JSON snippets and reproducer data model) is in the linked issue.

Fix

  useVirtualPeerlink: {{ vpc_peers_pair.fabric_peering | default(false) }}

This aligns the rendered payload with:

• The documented dcnm_vpc_pair default — useVirtualPeerlink: { type: bool, default: false }.
• The existing validation rule roles/validate/files/rules/ibgp_vxlan/208_manual_ipaddress_allocation.py, which already uses peer.get("fabric_peering", False).
• The reference data model nac-fabric1, which sets fabric_peering: false explicitly and works end-to-end.

Scope

• One file changed: roles/dtc/common/templates/ndfc_vpc/ndfc_vpc_peering_pairs.j2.
• No behavior change for entries that already define fabric_peering (rendering for those is bit-identical).

Verification

Manual Jinja render against three cases (fabric_peering: true, fabric_peering: false, omitted):

- peerOneId: 10.122.226.107
  peerTwoId: 10.122.226.108
  useVirtualPeerlink: True

- peerOneId: 10.122.226.115
  peerTwoId: 10.122.226.116
  useVirtualPeerlink: False

- peerOneId: 10.122.226.105
  peerTwoId: 10.122.226.106
  useVirtualPeerlink: False

The third case is the fix: previously, the useVirtualPeerlink line would not be emitted at all.

Related issue

Closes #800.