Track intermittent Data Proxy scale-unit TaskCanceledException as a reliability issue

Problem

The Template 19 testing guide currently documents an approximately 50% TaskCanceledException rate caused by Data Proxy being available on only one of two scale units, with --retry as the workaround.

Retries help the test complete, but they can also hide a product-path reliability problem and make successful private networking appear nondeterministic.

Suggested improvement

Track this as a product reliability item and make the sample diagnostics distinguish it from customer DNS or network failures.

Suggested additions:

• emit a dedicated result such as DATAPROXY_SCALE_UNIT_RETRY when this exact signature is detected;
• record attempt count and final outcome in machine-readable output;
• explain that a retry success does not mean the original failure was caused by customer DNS/NSG configuration;
• link to a product-status/known-issue reference when one is available; and
• remove or revise the documented 50% expectation once Data Proxy is consistently present across the serving scale units.

Expected result

Private MCP tests should be deterministic. Until the service-side issue is resolved, diagnostics should clearly separate transient Data Proxy routing from configuration failures.

No files or tests are named. Start with the Template 19 testing guide and the sample diagnostics that implement the private MCP tests; trace how TaskCanceledException and retry outcomes are currently reported. Done means the diagnostics distinguish the stated Data Proxy signature from configuration failures and expose attempt count and final outcome in machine-readable output.