Track running the emitter against all existing TypeSpec files

## 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](https://github.com/Azure/azure-rest-api-specs) (ARM + data-plane TypeSpec definitions)
- **Spector test suites** from [http-specs](https://github.com/microsoft/typespec/tree/main/packages/http-specs/specs) and [azure-http-specs](https://github.com/Azure/typespec-azure/tree/main/packages/azure-http-specs/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.