Fast Path Pipeline: Deterministic deploy templates

Part of #557

## Problem

The Copilot agent generates a different workflow each time — and the generated workflows have recurring bugs: single-job design, missing permissions, unpinned kubelogin, fragile `sed`-based image substitution, and no explicit Dockerfile path. These are the root causes of most deploy failures.

When we already have the user's config (cluster, namespace, ACR, Dockerfile path, container settings), we can generate a correct workflow and manifests deterministically from tested templates.

## Changes

Create `fastPathTemplates.ts` with three pure functions:

- **`generateDeployWorkflow()`** — produces a two-job workflow (`buildImage` + `deploy`) based on the proven aks-devhub pattern. Fixes all known bugs: pinned `kubelogin-version: 'v0.1.6'`, `Azure/k8s-deploy@v5` for image substitution, `actions: read` permission, explicit `DOCKER_FILE` and `BUILD_CONTEXT_PATH` env vars, `continue-on-error` on annotations.
- **`generateDeploymentManifest()`** — Deployment YAML parameterized from ContainerConfig (replicas, resources, probes, security context, anti-affinity, pipeline annotations)
- **`generateServiceManifest()`** — Service YAML with configured type, ports, and selector

All functions are pure (config in → string out) with comprehensive test coverage.

Start by locating ContainerConfig and the existing aks-devhub workflow pattern, then create fastPathTemplates.ts with the three named pure generators. Add comprehensive tests for the generated workflow and manifests, including the listed permissions, pinned action, paths, substitutions, and configured deployment and service fields; done means config-in strings match the tested templates.

Written by the indexing model from the issue text.