Fix data-plane spec discovery and code generation

[Jian Hui (huiii99)]

Problem

Data-plane resource provider discovery relied on directory names containing a dot. After upstream specifications renamed Microsoft.* directories, valid providers were no longer discovered, while some example/version directories were incorrectly treated as providers.

Code generation also rejected error models containing a literal property named additionalProperties, blocking services such as monitor/OperationalInsights.

Related workflows exposed duplicate TypeSpec entries, incorrect submodule paths and resource-version API arguments, and unreliable AAZ loader detection. Skipping providers without a default tag could also produce an incomplete CLI profile and remove existing commands during generation.

Changes

• Discover data-plane providers from stable/preview directories while retaining support for legacy dotted names. Exclude hidden, common, and example directories, and eliminate duplicate TypeSpec discovery.
• Recognize the literal additionalProperties error property consistently in Python and TypeScript, preserving the existing format checks.
• Preserve root-level TypeSpec submodule paths and fall back to the plane-specific OpenAPI layout. Correct the resource-version API argument order.
• Abort CLI generation when tags or command models are missing, or when resource/command selections are empty, rather than overwrite a profile with incomplete results.
• Use AST-based loader detection for load_command_table and its local helpers. Support standard and args-guided loaders, including import aliases, without treating comments or unused imports/helpers as registered commands.
• Update affected test fixtures and add targeted regression coverage.

Validation

• Targeted Python regression tests: 3 tests and 19 subtests passed.
• TypeScript emitter build succeeded; all 16 Vitest tests passed.
• OperationalInsights: all four resources generated command models successfully.
• Management-plane discovery sets and monitor API payloads remained unchanged in baseline comparisons.
• Verified restored TypeSpec submodule access and patch behavior for monitor, interactive, and apim.

Testing Guide

Assume the required repositories are already cloned and the Python virtual environment is activated. Run the following from this PR's aaz-dev-tools checkout.

Setup and start

Install the local Python code and build the frontend/emitter assets:

$env:PYTHONIOENCODING = 'utf-8'
python -m pip install -e . pytest pytest-subtests

git submodule update --init --recursive
pnpm install
pnpm build:typespec
pnpm build:web
pnpm bundle

Start the service using your local repository paths:

$root = 'C:\Users\...' # Adjust to your local directory

aaz-dev run `
    --cli-path "$root\azure-cli" `
    --cli-extension-path "$root\azure-cli-extensions" `
    --swagger-path "$root\azure-rest-api-specs" `
    --aaz-path "$root\aaz"

UI checks

Open http://127.0.0.1:5000.

1. Data plane: Create an OpenAPI workspace for Data plane → monitor → OperationalInsights. Select API version v1 and add all four resources. Command models should generate without the unsupported error-schema error. If client configuration is required, use endpoint https://api.loganalytics.io and AAD scope https://api.loganalytics.io/.default.
2. Control plane: Create a workspace for Control plane → monitor → Microsoft.Insights. Verify the resource list and generate an actionGroups resource using 2024-10-01-preview. Provider/resource lists should match the base commit when using the same specs revision.
3. CLI generation: Export the workspace models to AAZ, then generate into a new test extension using Generate Edited Only. Verify that command files are generated. Avoid regenerating an existing monitor or network CLI module for this smoke test.

Automated checks

Run in another terminal using the same virtual environment, from the PR checkout:

$env:PYTHONIOENCODING = 'utf-8'
python -m pytest src\aaz_dev\cli\tests\test_codegen_regressions.py -q
pnpm -C src\typespec-aaz test-aaz

These cover generation safeguards, management/data-plane submodule paths, patch idempotence, and error-format handling. The emitter must be built before testing because the tests consume dist files.

After testing, inspect the repository diffs. Only the intended AAZ models and new test-extension files should have changed; existing CLI modules should remain untouched.