[release/13.6] Correct context-based endpoint resolution guidance

[danegsta]

Problem

The Context-based endpoint resolution section in src/frontend/src/content/docs/architecture/resource-hierarchies.mdx contains stale and overgeneralized descriptions that don't account for the container tunnel behavior documented in #1723.

Container-to-host resolution

The current resolution table says:

| Container | Executable / Project | Host network (`host.docker.internal:port`). | `host.docker.internal:5000` |

With the container tunnel enabled—the default behavior—the endpoint is projected through the Aspire container tunnel address, such as aspire.dev.internal:<port>. A container host address such as host.docker.internal:<port> is used when the tunnel is disabled. The table should distinguish these cases rather than presenting the disabled-tunnel behavior as universal.

Default container network description

The current list says:

DefaultAspireContainerNetwork: Resolves to container network URLs using resource names

Resource-name DNS describes container targets, but it doesn't describe project or executable targets. Those endpoints resolve through the container tunnel when enabled, or through the container host name when disabled. The description should define the network identifier as the endpoint's reachability context rather than prescribing one hostname form.

Container resource prerequisite

The section should also explain that the default Aspire container network is created only when the app model contains at least one container resource. Explicitly resolving a project or executable endpoint for DefaultAspireContainerNetwork without any container resources fails with an actionable resource-scoped error.

Expected update

• Correct the container-to-project/executable row in the resolution table.
• Qualify the DefaultAspireContainerNetwork description by target resource type and tunnel state.
• Document the container-resource prerequisite for the default network.
• Review the surrounding examples and comments for assumptions that all container-network endpoints use resource-name DNS.

This should be fixed in the release/13.6 documentation.