[Jian Hui (huiii99)]

Problem

Workspace export and CLI generation for network application-gateway each take roughly 1.7-2 hours, while smaller command groups finish in seconds.

Root Cause

The application-gateway cfg contains 146 commands in 15.2 MB. Both flows repeatedly deserialize the entire shared cfg for individual commands, at roughly 36-40 seconds per parse.

This PR processes each workspace cfg editor once during export and caches parsed readers by (plane, resource_id, version) within each CLI profile. Workspace cache entries are readonly snapshots: writers load independent editors, restore class-reference links, and publish only after a successful save.

Benchmark

Same inputs on AMD EPYC 7763, Python 3.12.10, schematics 2.1.1. Application Gateway uses API version 2026-01-01; CLI generation uses PATCH mode with its commands marked modified.

Scenario	Before	After
Application Gateway: export	6,088.5 s	183.4 s
Application Gateway: CLI generation	7,032.9 s*	67.1 s
VNet subnet: export	12.0 s	10.8 s
VNet subnet: CLI generation	10.0 s	8.5 s

The original CLI run overlapped with the original export run, so its baseline includes resource contention.

Testing

• Byte-identical outputs for Application Gateway (25,427 AAZ files and 474 CLI files), VNet subnet, and full PUT generation of edge-order (53 files).
• Broader API/codegen comparison: 29 passed; the same 8 failures also occur on the original code in the local environment.
• Focused cache/editor/codegen suite: 17 passed; 2 pre-existing failures confirmed against the pre-fix code.
• Regression tests cover cache-hit class links after save, continuous editing, failed-write isolation for existing readonly references, and one resource load per manager. Original Databricks reproductions also pass.