.NET: Fix duplicate Foundry AgentHost port binding

[Roger Barreto (rogerbarreto)]

Motivation & Context

Microsoft.Agents.AI.Foundry.Hosting added automatic port configuration for hosted applications created with WebApplication.CreateBuilder. Applications created with the documented AgentHost.CreateBuilder path already receive a Kestrel listener from AgentServer. Registering both listeners on port 8088 causes every hosted container to fail during startup and the client to receive HTTP 424 session_not_ready.

This change restores the documented AgentHost.CreateBuilder path while preserving automatic port configuration for standalone ASP.NET applications.

Description & Review Guide

• What are the major changes? AddFoundryResponses now initializes the Foundry server URL through an ASP.NET startup filter before the server reads its configured addresses. A code-configured AgentHostBuilder listener takes precedence over that URL and remains the only Kestrel endpoint. A standalone WebApplicationBuilder uses the URL as its only listener. This avoids inferring the builder type from public service registrations. Unit tests cover both paths, including a standalone host with an explicit ServerVersionRegistry instance. The live hosted integration suite runs its happy-path scenario with AgentHost.CreateBuilder, while the remaining scenarios continue to cover WebApplication.CreateBuilder.
• What is the impact of these changes? Both supported hosting paths configure exactly one effective listener. Hosted containers using AgentHost.CreateBuilder can start and pass the readiness probe without requiring application changes or a package downgrade. Standalone hosts continue to override the base image URL with the Foundry port.
• What do you want reviewers to focus on? Please review the startup filter timing, the Kestrel address precedence, and the decision to cover both host builders within the existing live integration image.

Related Issue

Fixes #7617

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Fixes duplicate port binding when Foundry hosting uses AgentHost.CreateBuilder, while preserving standalone ASP.NET hosting behavior.

Changes:

• Detects AgentHost-owned listener configuration.
• Adds unit coverage for both hosting paths.
• Exercises AgentHost in live integration tests.

Reviewed changes

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

Show a summary per file

File	Description
ServiceCollectionExtensions.cs	Avoids duplicate Kestrel listener registration.
FoundryListenPortTests.cs	Tests AgentHost and standalone registration.
Program.cs	Uses AgentHost for the happy-path scenario.
HappyPathHostedAgentTests.cs	Verifies AgentHost startup and responses.
README.md	Documents hosting-path coverage.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: Findings reported
Scope: full PR (1 commit(s)): 4e1df00b6fe2
Model: gpt-5.6-sol

Overview

The change checks for the registry instance installed by AgentHostBuilder before protocol registration, preserving the package-owned listener for ordinary ASP.NET hosts while avoiding the duplicate AgentHost listener. The tests cover both documented builder paths, repeated registration, configured ports, and real AgentHost build output. However, the selected registry is also a public standalone-host service, so its registration shape is not an exclusive host-builder marker and can suppress the only Foundry listener.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
1 verified finding remained after source verification (1 medium) across 1 file. Details are attached to the affected lines below.

Affected areas: dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/ServiceCollectionExtensions.cs