Omit sudo from generated lock.yml when network-isolation sandbox is enabled

[lpcox]

Summary

When the AWF network-isolation sandbox option is enabled (sandbox.agent.network-isolation: true), the compiler still emits sudo in the generated .lock.yml for the awf binary install and the awf invocation. In network-isolation mode, AWF no longer needs NET_ADMIN/host-iptables egress enforcement, so it can run rootless — a key requirement for ARC (Actions Runner Controller) Kubernetes runners where passwordless sudo/host-iptables are often unavailable.

The compiler should omit sudo from the generated lock when network-isolation is enabled.

Current behavior

For a workflow with sandbox.agent.network-isolation: true, the generated lock contains (line numbers from a real compile):

# Install awf binary
sudo tee /usr/local/bin/awf > /dev/null <<EOF
...
sudo chmod +x /usr/local/bin/awf

# Run awf
sudo -E awf --config ... --build-local -- /bin/bash -c '...'

Desired behavior

When network-isolation is enabled, emit the same steps without sudo (and without -E, since the env is already exported in the step):

tee /usr/local/bin/awf > /dev/null <<EOF
...
chmod +x /usr/local/bin/awf

awf --config ... --build-local -- /bin/bash -c '...'

The artifact-upload permission-fix step (sudo chmod -R a+rX /tmp/gh-aw/sandbox/firewall …) can remain, or ideally also be dropped/guarded since rootless runs no longer create root-owned files.

Evidence (validated rootless)

Manually editing the generated lock to remove sudo from the install + awf invocation (keeping only the artifact-upload sudo) and re-running the network-isolation smoke workflow passes end-to-end without root:

• awf --config … runs without sudo
• Local binary install (tee /usr/local/bin/awf, no sudo) succeeds
• Egress enforcement intact: allowed domain → allowed=200; non-allowed example.com blocked with CONNECT tunnel failed, response 403
• Firewall summary: 15 requests, 12 allowed, 3 blocked

Reference (gh-aw-firewall): PR github/gh-aw-firewall#5495 and passing rootless run https://github.com/github/gh-aw-firewall/actions/runs/28114712549

Notes / edge cases

• Without sudo, a benign cleanup warning can appear because container-created files under the chroot-home are root-owned:
  [WARN] Failed to clean up temporary files: EACCES, Permission denied: /tmp/awf-...-chroot-home
  Worth handling (e.g. rootless cleanup, or running the container with the host UID) so the warning disappears.
• The awf invocation still launches Docker/compose; this requires the runner user to be in the docker group (true for GitHub-hosted runners and standard ARC DinD setups).
• This should be gated strictly on the network-isolation option — the legacy host-iptables topology still needs sudo.

Acceptance criteria

• With sandbox.agent.network-isolation: true, the generated .lock.yml contains no sudo for the awf binary install or the awf invocation.
• Legacy (non-isolation) topology is unchanged (still uses sudo).
• A compiled network-isolation workflow runs successfully on a rootless/ARC-style runner.

---

Additional ask: bump default firewall + mcpg container versions to latest

Alongside the sudo change, please bump the default pinned container versions the compiler uses to the current latest releases:

• Firewall (ghcr.io/github/gh-aw-firewall/{agent,api-proxy,squid}): v0.27.10
• MCP gateway (ghcr.io/github/gh-aw-mcpg): v0.3.30

These are the latest published releases (both verified resolvable on GHCR) and contain the network-isolation topology egress model. Updating the gh-aw defaults means workflows that don't explicitly pin sandbox.agent.version / sandbox.mcp.version pick up the topology-capable images automatically.

Acceptance criteria (versions)

• Default firewall container version bumped to v0.27.10.
• Default mcpg container version bumped to v0.3.30.
• Recompiled lock files reference the new tags.