Track running the emitter against all existing TypeSpec files

[RickWinter]

Summary

We should run the TypeSpec Rust emitter against all existing TypeSpec specification files to validate emitter correctness, identify unsupported features, and catch codegen failures early. This includes:

• Azure REST API specs from azure-rest-api-specs (ARM + data-plane TypeSpec definitions)
• Spector test suites from http-specs and azure-http-specs

Goals

1. Identify gaps — Catalog which specs the emitter can successfully generate code for and which fail
2. Categorize failures — Classify failures by root cause (unsupported features, codegen bugs, TCGC issues, etc.)
3. Track coverage — Establish a baseline of emitter coverage across the full spec surface
4. Prevent regressions — Once a spec successfully generates, ensure it continues to do so

Acceptance Criteria

• Run the emitter against all TypeSpec files in azure-rest-api-specs and record results
• Run the emitter against all Spector spec suites (http-specs + azure-http-specs) and record results
• Produce a report categorizing each spec as: ✅ success, ⚠️ generates with warnings, ❌ fails
• For failures, file or link to tracking issues for each root cause
• Verify generated Rust code compiles (cargo check) for all successful specs
• Document any specs that are blocked on upstream issues (e.g., TCGC, typespec-azure)

Notes

• Some specs may fail due to known unsupported features (e.g., non-discriminated unions per #969 in the adapter). These should be cataloged, not necessarily fixed as part of this work.
• Consider automating this as a periodic CI job once the initial pass is complete.