[APIView] Project/package linking from multi-emitter TypeSpec metadata

[AlitzelMendez]

closes: #14975

Projects now correctly handle TypeSpec specs where:

• A language has more than one emitter but a single underlying SDK package

The database looks like

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Fixes project-to-package/review linkage and namespace decision handling for TypeSpec metadata scenarios where a single language can emit multiple SDK packages, and improves project lookup efficiency via a flattened package token index.

Changes:

• Extend TypeSpec metadata and project models to support multiple packages per language and multiple review IDs per language.
• Add PackageLookup tokens (language::packagename) for efficient Cosmos queries when linking reviews to projects.
• Update namespace decision data structures and UI/API flows to support multiple active namespace entries per language (per package).

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/dotnet/APIView/ClientSPA/src/app/_services/projects/projects.service.ts	Updates namespace status API payload to include the namespace identifier.
src/dotnet/APIView/ClientSPA/src/app/_models/projectModel.ts	Changes related reviews shape from language map to array.
src/dotnet/APIView/ClientSPA/src/app/_models/namespaceModel.ts	Changes current namespace status to multi-entry per language.
src/dotnet/APIView/ClientSPA/src/app/_components/namespace-page/namespace-page.component.ts	Builds rows per (language, package) namespace entry and deduplicates revision fetches.
src/dotnet/APIView/APIViewWeb/Repositories/CosmosProjectRepository.cs	Switches project lookup-by-package to PackageLookup/ARRAY_CONTAINS.
src/dotnet/APIView/APIViewWeb/Models/TypeSpecMetadataModel.cs	Supports multiple LanguageConfig entries per language.
src/dotnet/APIView/APIViewWeb/Models/ProjectModel.cs	Stores multiple expected packages per language, adds PackageLookup, and multiple review IDs per language.
src/dotnet/APIView/APIViewWeb/Models/NamespaceModel.cs	Stores multiple current namespace decisions per language.
src/dotnet/APIView/APIViewWeb/Managers/ProjectsManager.cs	Builds/uses multi-package expected packages, maintains multi-review links, and generates PackageLookup.
src/dotnet/APIView/APIViewWeb/Managers/NamespaceManager.cs	Updates namespace approval/update logic to operate on specific namespace entries per language/package.
src/dotnet/APIView/APIViewWeb/Managers/Interfaces/INamespaceManager.cs	Updates interface to accept namespace identifier and multi-package dictionaries.
src/dotnet/APIView/APIViewWeb/LeanControllers/ProjectsController.cs	Adjusts related review retrieval and namespace status resolution for multi-entry states.
src/dotnet/APIView/APIViewWeb/Helpers/LanguageServiceHelpers.cs	Expands language alias mapping (e.g., dotnet→C#, ts/typescript→JavaScript).
src/dotnet/APIView/APIViewUnitTests/TypeSpecMetadataIntegrationTests.cs	Updates integration tests for multi-config-per-language metadata.
src/dotnet/APIView/APIViewUnitTests/ProjectsManagerTests.cs	Updates tests for multi-review-per-language and multi-package-per-language behavior.
src/dotnet/APIView/APIViewUnitTests/NamespaceManagerTests.cs	Expands tests for multi-entry namespace behaviors and a real-world multi-package scenario.
src/dotnet/APIView/APIViewUnitTests/CodeFileManagerTests.cs	Updates tests for metadata language configs now being lists.
src/dotnet/APIView/APIViewUnitTests/APIRevisionsManagerTests.cs	Updates tests for metadata language configs now being lists.

[Copilot]

Pull request overview

Copilot reviewed 18 out of 18 changed files in this pull request and generated 3 comments.

[tjprescott]

A few questions.

It seems like most of the tests were just upgraded in place to use a single entry array. But we've seen at least two scenarios where I'm very curious how we handle them:

1. The Java scenario where there is one tspconfig entry with a "flavor" key that changes the scope of approval (the azure vs azurev2 scenario). Yet end up with two packages with different namespaces from different emitters.
2. The C# scenarios where there are two tspconfig entries that point to the SAME namespace and only one package gets generated.
3. The other C# scenarios where there are two tspconfig entries that point to different namespaces and generate different packages.

Are we accommodating these scenarios?

[tjprescott]

Still not entirely following. Might make more sense to just have a call to discuss.