feat(agents): validate .NET runtime vs TargetFramework after init

[v1212]

Summary

• Adds a non-blocking post-init validation framework (validatePostInit) that runs after azd ai agent init completes
• First validator: checks .NET runtime selection against .csproj TargetFramework prints a clear ERROR (red) with fix instructions if target > runtime (which will fail at build/deploy time)
• Prints green OK message when validation passes
• Prints ERROR when .csproj cannot be read, prompting user to verify manually
• Does NOT block or alter the init flow in any way purely advisory output
• Wired into both template flow (init.go) and from-code flow (init_from_code.go)
• Python projects and container deploys are unaffected (skipped)

Changes

File	Description
init_validate.go	New: validation framework + .NET runtime vs TargetFramework check
init_validate_test.go	New: comprehensive unit tests (mismatch, match, higher runtime, no csproj, unreadable dir, python skip)
init.go	Call validatePostInit after template init completes
init_from_code.go	Call validatePostInit after from-code init completes

Closes #8202

E2E Test Results (Manual Interactive Testing)

All tests run interactively using only azd ai agent init + azd deploy (no file modifications).

Test	Scenario	Result
V1-P1	C# Template Invocations, .NET 9 vs net10.0 csproj ERROR message	PASS
V1-P2	C# Template Invocations, .NET 10 vs net10.0 csproj OK + deploy + invoke	PASS
1	Python Template Invocations, remote_build deploy invoke	PASS
3	Python Template Responses, remote_build deploy invoke	PASS
6	Python From-code vNext Responses, remote_build deploy invoke	PASS
A	C# Template Invocations, .NET 10 remote_build deploy invoke	PASS
B	C# Template Responses AgentFW, .NET 10 remote_build deploy invoke	PASS

7/7 passed PR feature (runtime validation) works correctly, no regressions in init/deploy/invoke flows.

[Copilot]

Pull request overview

Adds a non-blocking, advisory post-azd ai agent init validation that compares the selected .NET runtime (dotnet_N) against the TargetFramework in the project's .csproj. If the target framework is higher than the selected runtime (a known cause of confusing remote-build failures), a red ERROR with fix instructions is printed; matching configurations print a green OK; Python and missing-.csproj cases are skipped. The validator is wired into both the template-based init flow and the from-code init flow, and never alters or blocks init.

Changes:

• New init_validate.go with validatePostInit framework and validateDotnetRuntimeVsCsproj check, including a simple <TargetFramework>netX.Y</TargetFramework> regex parser.
• New init_validate_test.go covering match, mismatch, higher-runtime, no-csproj, unreadable-dir, Python-skip, and nil code-config cases.
• init.go and init_from_code.go invoke validatePostInit after their respective init flows complete.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
cli/azd/extensions/azure.ai.agents/internal/cmd/init_validate.go	New validation framework + .NET runtime vs TargetFramework check.
cli/azd/extensions/azure.ai.agents/internal/cmd/init_validate_test.go	Unit tests for the new validator and its scenarios.
cli/azd/extensions/azure.ai.agents/internal/cmd/init.go	Calls validatePostInit after template init completes (guarded by ContainerAgent assertion).
cli/azd/extensions/azure.ai.agents/internal/cmd/init_from_code.go	Calls validatePostInit after from-code init completes.

[v1212]

.

[jongio]

Clean addition - advisory only, nil-safe, can't break existing flows. Two items below worth a look.

[trangevi]

/check-enforcer override

[trangevi]

I'd like @therealjohn to take a look at this. On the surface I'm ok with it, but I'm a little concerned with the idea of adding warnings/error messages just before we say "everything is good you're done".