WrapperGenerator: wire generated modules into src/{Module} with per-module namespaces

[Joywambui-maina]

Summary
Generated modules are throwaway test builds under artifacts/; wire them into the real repo layout with per-module namespaces and a beta prefix so they can become shippable.

What's working now
Build-WrapperModule.ps1 builds any module into an importable PSD1 (kiota client + wrappers + dll + manifest), and all 35 cmdlet-producing v1.0 modules build and pass import smoke tests.

How can we make it better
Every module shares one hard-coded MgPoC cmdlet namespace, the generated csproj contains a machine-local absolute path and is marked do-not-commit, and nothing lands in src/{Module}/ where real modules live. There is also no MgBeta noun prefix, so beta modules cannot generate correct cmdlet names at all. Add a namespace/prefix option to the generator, emit a committable project layout under src/{Module}/, and decide the target framework for shipping.

[Joywambui-maina]

Already implemented

• Build-WrapperModule.ps1 generates both required source layers from the same OpenAPI document:
  • the Kiota client under Client/
  • the PowerShell wrapper cmdlets under Cmdlets/
• -IntoSource defines a source layout under src/<Module>/v1.0/wrapper/.
• Generated clients use module-specific namespaces.
• Generated wrapper projects use relative references to the client and Authentication projects.
• Client and wrapper project templates exist as standalone files.
• Wrapper-specific build, test, parity, and collision gates exist for artifact builds.
• The current KiotaCompat v1.0 input contains 38 module specifications, and local artifact output exists for all 38 modules.

Partially implemented

• The script can emit a self-contained source directory, but this capability has not been exercised into the repository source tree.
• Standalone wrapper artifacts compile locally, but they are separate test modules named Microsoft.Graph.Wrapper.<Module>.
• The wrapper-specific gates validate artifact builds, but they are not part of the production build or packaging path.

Not implemented

• There are currently zero tracked files under src/*/v1.0/wrapper/.
• Neither generated Kiota client sources nor generated cmdlet sources are committed under src.
• A clean checkout cannot build the wrappers without first running generation.
• Generation requires an arbitrary globally installed kiota executable; no repository-pinned Kiota tool manifest exists.
• build.proj, GenerateModules.ps1, GenerateServiceModule.ps1, ManageGeneratedModule.ps1, and PackModule.ps1 do not consume wrapper projects.
• Wrapper assemblies are not incorporated into the real Microsoft Graph module manifests or packages.
• Public versus internal worker-command exports remain unresolved.
• Cross-module public command collisions must be resolved before the wrappers can be loaded together.
• The shipping target framework is unresolved:
  • wrapper templates hard-code net10.0
  • Authentication currently targets netstandard2.0
• Framework-specific output discovery is hard-coded to bin/<Configuration>/net10.0.
• Dependency versions such as Microsoft.Kiota.Bundle are embedded directly in templates rather than coming from an authoritative repository configuration.

[Joywambui-maina]

Closed in #3733