Add per-workflow version override feature flags for Copilot, MCP gateway, AWF, and engine CLIs

[Copilot]

This PR adds workflow-level version feature flags to smoke-test new runtime/CLI versions without changing global pinned defaults. The compiler now resolves these overrides at generation time across install steps and container image references.

• Feature flag surface

  • Added/updated constants in pkg/constants/feature_constants.go:
    • copilot-version
    • mcpg-version
    • firewall-version
    • codex-version
    • claude-version
    • opencode-version
    • gemini-version
  • Added NoFeatureFlag sentinel for explicit non-override call sites.
  • Uses getFeatureValue(flag, workflowData) string in pkg/workflow/features.go to read string-valued feature flags (case-insensitive, trimmed).

• Engine/installer version resolution

  • Added centralized version resolution precedence for engine CLI installs:
    1. explicit engine.version
    2. feature flag version override
    3. pinned default version
  • Applied across Copilot/Codex/Claude/OpenCode/Gemini paths (Crush remains no feature override).
  • Copilot byok-copilot continues to force latest after shared resolution.

• Copilot override

  • Updated CopilotEngine.GetInstallationSteps() to use features.copilot-version.
  • Supports both specific versions and latest.

• AWF/firewall override

  • Updated firewall config resolution (getFirewallConfig) to apply features.firewall-version when network.firewall.version is not explicitly set.
  • This affects:
    • AWF binary install version
    • AWF --image-tag generation
    • AWF container image tags (agent, api-proxy, squid) in predownload flow.
  • Updated install_awf_binary.sh so latest is meaningful for executable installs (uses releases/latest/download).

• MCP gateway override

  • getMCPGatewayVersion(workflowData, configuredVersion) now uses features.mcpg-version when explicit sandbox.mcp.version is not set.
  • Applied to:
    • default MCP gateway config population
    • MCP gateway startup container image generation
    • docker image predownload collection

• Targeted coverage updates

  • Added/extended tests for:
    • string feature value extraction
    • version precedence (engine.version over feature override)
    • latest and specific-version handling for Copilot/Codex/Claude/OpenCode/Gemini installers
    • firewall-version in AWF install/image-tag/docker images
    • mcpg-version defaulting + precedence with explicit sandbox.mcp.version

features:
  copilot-version: "latest"
  mcpg-version: "v0.2.27"
  firewall-version: "v0.25.27"
  codex-version: "latest"
  claude-version: "2.1.47"
  opencode-version: "latest"
  gemini-version: "0.37.2"

[lpcox]

@copilot make all of the feature flags *-latest instead of just copilot

[Copilot]

@copilot make all of the feature flags *-latest instead of just copilot

Done in dcf63b3 — the new flags now use a consistent *-latest naming:
copilot-latest, mcpg-latest, and firewall-latest (with constants/usages/tests updated).

[lpcox]

@copilot change feature flags to copilot-version, mcpg-version, firewall-version, codex-version, claude-version, opencode-version, and gemini-version and allow "latest" as a possible value as well as a specific version number. make sure that for the value is meaningful. for example, "latest" is a tag for the container version but not specificying a version will download the latest agent executable. "latest" may need to be a special value for the agent flags.

[Copilot]

@copilot change feature flags to copilot-version, mcpg-version, firewall-version, codex-version, claude-version, opencode-version, and gemini-version and allow "latest" as a possible value as well as ...

Implemented in bfb80dc (plus preceding commits in the same change set): feature flags are now copilot-version, mcpg-version, firewall-version, codex-version, claude-version, opencode-version, and gemini-version, each supporting either latest or a specific version string.

latest is now meaningful for AWF executable install as well (install_awf_binary.sh now resolves via releases/latest/download), while container paths continue to use tag semantics. Explicit engine.version/sandbox.mcp.version still take precedence when set.

[pelikhan]

@copilot why do we need this?

[Copilot]

@copilot why do we need this?

It gives us a safe per-workflow rollout mechanism for engine/runtime upgrades without changing global defaults. We can pin stable defaults for everyone, then selectively test latest or specific versions in a few workflows, compare behavior, and rollback by editing frontmatter only. It also makes semantics explicit: no version set => pinned default; feature set => override (latest or exact version); explicit engine.version / sandbox.mcp.version still wins.

[lpcox]

@copilot remove all feature flags from the pr but add sandbox.agent.version to the front matter so that the firewall version can be set just like sandbox.mcp.version sets the mcpg version. engine versions can already be set.