Replace microsoft-foundry skill direct-code deploy pipeline with a script

## Summary

Copilot has identified a portion of a skill that is a good candidate for replacement with a script.

The candidate is the **direct-code deploy pipeline** in the `microsoft-foundry` skill (`foundry-agent/deploy/references/direct-code-deployment.md`) — a build-zip → SHA-256 → multipart upload → poll-until-terminal pipeline, analogous to `docker build → tag → push → wait`.

## Candidate description

To deploy agent code directly, the skill runs a fixed pipeline:

1. Build a flat zip excluding a fixed set of dev artifacts (Task 5).
2. Compute the zip's SHA-256 (Task 6).
3. Existence-check `GET`, then create/version `POST` as `multipart/form-data` with `metadata` / `code` / `x-ms-code-zip-sha256` and the exact `Foundry-Features` header set.
4. Poll `GET .../versions/` until status leaves `creating`, then branch on `active` / `failed` (Task 7).

This is a strong script candidate because it is:
- **A canonical fixed pipeline** — the build/hash/upload/poll archetype, with the zip and hash already embedded as scattered Python snippets a single script would consolidate.
- **Output-reducing** — the only poll-loop outputs that matter are the terminal status and (on failure) the version error.
- **Header/contract-encoding** — the `api-version` + `Foundry-Features` contract and the token idiom (`az account get-access-token --resource https://ai.azure.com`, shared with `tracing-insights-api.md` and `troubleshoot.md`) are pinned once.

**Sketch — `deploy-agent-code.{sh,ps1}`:**
- **Input:** the resolved runtime / packaging mode / create-vs-version route (as parameters), `--source-dir`, `--endpoint`.
- **Output:** "deployed version N, status active" on success, or the version error on failure.

> Runtime/entry-point detection (Tasks 2–3), remote-vs-bundled dependency packaging, and the create-vs-create-version-vs-in-place decision (Task 6 table) require judgment and stay agent-driven; the script accepts the resolved runtime/mode/route as parameters. The zip/hash/upload/poll mechanics below those decisions are scriptable.

## Affected file and lines

- [`foundry-agent/deploy/references/direct-code-deployment.md` — zip → SHA-256 → multipart upload → poll (L150–L340)](https://github.com/microsoft/GitHub-Copilot-for-Azure/blob/3890cbfb65c548ce8daa96cabd1d8de63f7bbcca/plugin/skills/microsoft-foundry/foundry-agent/deploy/references/direct-code-deployment.md#L150-L340)

## Next steps

1. **Evaluate the candidate** — confirm the steps are stable and parameterizable, and that the script captures everything the skill needs.
2. **Create both a bash _and_ a PowerShell version** of the script so the skill works across platforms.
3. **Run integration tests** to verify the scripts behave correctly and the skill still completes end-to-end.

## Background Information

### Why replace regular steps with scripts

Replacing a regular, well-defined series of steps with a script can:

- **Reduce token usage** — the skill no longer needs to spell out each command and parse large command output inline; the agent invokes one script and reads a compact result.
- **Improve reliability** — the logic is written and tested once, instead of being re-derived by the agent on every run.
- **Improve determinism** — the same inputs always produce the same steps and output, removing run-to-run variation.
- **Improve speed of execution** — a single script call replaces multiple round-trips of command generation, execution, and large-output parsing.

### Authoring notes for the scripts

- **Reference scripts with markdown links**, not just a bare path to the script file.
- **Include examples** in the skill showing how to run each script (sample invocation with arguments).
- **Briefly explain what each script does** where it is referenced.
- **The script output should explain what it did**, so the agent and user can understand the result without re-inspecting raw command output.