microsoft-foundry skill: gaps and inaccuracies for hosted-agent + azd workflows (found via real multi-agent repo)

## Summary
While using the `microsoft-foundry` skill to drive a real Foundry hosted-agent
project (two `host: azure.ai.agent` services in one `azd` project, container
deploy via ACR remote build, Teams/activity-protocol channel, and a
Durable-Task-backed long-running agent), I found several places where the
`foundry-agent/create` and `foundry-agent/deploy` sub-skills are either
inaccurate or missing coverage. Filing these together since they all surfaced
from the same real-world walkthrough.

**Reference repo (public, reproducible):**
https://github.com/microsoft/Build26-BRK241-from-prototype-to-production-build-and-run-agents-at-scale

## Findings

### 1. `deploy.md` overstates the Docker/Podman requirement for container deploys
`foundry-agent/deploy/deploy.md`'s Quick Reference table states container/ACR
deploy "requires Docker/Podman + ACR." When `azure.yaml` sets
`docker.remoteBuild: true` (ACR remote build), the build happens server-side
and **no local container engine is required at all**. This is a real
onboarding blocker if a dev machine has no Docker installed and the skill
tells them it's mandatory.

**Suggested fix:** Add a note/row distinguishing `remoteBuild: true` (no local
engine needed) from local build (`remoteBuild: false`/absent, Docker/Podman
required).

### 2. No documented recipe for adding a second hosted-agent service to an existing azd project
`foundry-agent/create/create-hosted.md` covers adding a second **model
deployment** in detail (`azure.yaml services..config.deployments[]`),
but not adding a second **agent service**. A real project can have multiple
independent `host: azure.ai.agent` services sharing one Foundry project
(e.g. `fibey-coordinator` + `field-ops-agent` in one `azure.yaml`). Re-running
`azd ai agent init` against the same project currently only documents the
name-collision-avoidance behavior for re-running against the *same* service,
not the intentional "add a sibling service" case.

**Suggested fix:** Add an explicit step-by-step for scaffolding an additional
service into an existing azd/Foundry project without triggering the
auto-suffix collision path.

### 3. No guidance on vendored/offline wheels for restricted-network container builds
Some hosted-agent projects ship a `wheels/*.whl` directory referenced by
`requirements.txt` for reproducible or air-gapped/regulated builds. Neither
`create-hosted.md` nor `deploy.md` mentions this pattern, its interaction with
`.dockerignore`, or when to prefer it over `remote_build` dependency
resolution.

**Suggested fix:** Add a short callout on vendored-wheel builds as an
alternative to `dependency_resolution: remote_build`.

### 4. `AZURE_TENANT_ID` isn't flagged as a pre-deploy requirement for postdeploy RBAC hooks
Projects that use a postdeploy hook to assign RBAC roles need
`AZURE_TENANT_ID` exported/set *before* `azd deploy` so the hook can
authenticate. `deploy.md` Step 1 ("Resolve azd environment") never mentions
checking/setting `AZURE_TENANT_ID`. Today this fails silently late — packaging
succeeds, then the `postdeploy` hook fails with an auth error, which is
confusing to debug from the skill's guidance alone.

**Suggested fix:** Add an `AZURE_TENANT_ID` check (e.g.
`az account show --query tenantId -o tsv`) to deploy Step 1, alongside the
existing subscription/location preflight guidance.

### 5. No sub-skill coverage for `activity_protocol` (Teams / Bot Framework) hosted agents
Hosted agents can declare `protocol: activity_protocol` (in addition to
`responses`) to become a Teams/Bot Framework channel — the platform passes the
raw Bot Framework Activity to the container's `/api/messages`, using the
agent's Entra Agent ID as the bot identity. The main `SKILL.md` sub-skill
table only documents `invocations-ws` for the duplex/voice protocol; there's
no equivalent reference for `activity_protocol`.

**Suggested fix:** Add a reference doc (mirroring `invocations-ws.md`)
covering the Activity protocol contract: bot identity, messaging endpoint
shape, and Teams channel provisioning.

### 6. No pattern doc for long-running / scale-to-zero + human-in-the-loop agents
Some hosted agents rely on Durable Task Scheduler to gate actions behind
human-in-the-loop approvals that survive scale-to-zero, with an in-process
fallback when no durable endpoint is configured. This is a common production
pattern for long-running coordinator-style agents, but it's undocumented
across `create`, `deploy`, `observe`, and `troubleshoot`.

**Suggested fix:** Add a reference doc under `foundry-agent/create/references/`
(e.g. `long-running-agents.md`) covering durable-orchestration wiring, the
optional-endpoint env var convention, and scale-to-zero implications for
session/state persistence.

## Suggested labels
`documentation`, `skill:microsoft-foundry`, `hosted-agents`, `azd`

Start with foundry-agent/deploy/deploy.md and foundry-agent/create/create-hosted.md, then review the main SKILL.md table and the existing invocations-ws.md reference. Document remote versus local builds, sibling hosted-agent services, vendored wheels, AZURE_TENANT_ID, activity_protocol, and long-running agents, with examples and pre-deploy expectations clear enough to follow.

Written by the indexing model from the issue text.