test(e2e): pin direct podman calls to harness socket on macOS

[russellb]

Summary

Fixes a macOS-only false failure in the Podman e2e harness. On macOS,
CONTAINER_ENGINE=podman mise run e2e:podman failed one test,
podman_gateway_start.rs::podman_gateway_restart_preserves_running_and_stopped_intent,
with:

Podman container for '<name>' did not reach running=true: podman ps failed:
Cannot connect to Podman... unable to connect to Podman socket:
... dial unix /var/folders/.../T/storage-run-<uid>/podman/podman.sock: no such file or directory

This is a test-environment bug, not a product bug, and it does not reproduce on Linux CI.

Related Issue

No linked issue. This is an obvious, localized bug fix in the e2e test harness
(macOS-only, no user-facing or product behavior change), which the contribution
conventions allow to proceed without an issue.

Changes

podman_gateway_start.rs is the only Podman e2e test that shells out to podman
directly (Command::new("podman") in sandbox_container_running); every other
Podman e2e test drives the gateway, which uses the pinned OPENSHELL_PODMAN_SOCKET.

The harness (e2e/with-podman-gateway.sh) exports XDG_CONFIG_HOME pointed at an
empty directory to isolate CLI/SDK gateway metadata. On macOS the podman client
resolves its VM connection config from XDG_CONFIG_HOME, so with it stripped a
bare podman ps falls back to a nonexistent native rootless socket and fails. On
Linux, rootless podman resolves its socket via XDG_RUNTIME_DIR, so the test passes
there — hence the macOS-only failure.

• Add a small podman_command() helper that passes --url unix://$OPENSHELL_PODMAN_SOCKET
  when the harness-exported OPENSHELL_PODMAN_SOCKET is set, targeting the exact socket
  the gateway uses and bypassing connection-config resolution — mirroring the shell's
  podman_cmd/with_podman_config helpers.
• Use it for both direct podman ps and podman inspect calls.
• When OPENSHELL_PODMAN_SOCKET is unset (running the test outside the harness), fall
  back to plain podman, so Linux behavior is unchanged.

Scope is limited to the e2e test harness; no product code is touched.

Testing

• Mechanism reproduced and verified on macOS:
  • XDG_CONFIG_HOME=$(mktemp -d) podman ps → fails with the exact reported
    storage-run socket error.
  • XDG_CONFIG_HOME=$(mktemp -d) podman --url "unix://$SOCK" ps → succeeds.
• mise run pre-commit → passed.
• macOS, targeted: OPENSHELL_E2E_PODMAN_TEST=podman_gateway_start CONTAINER_ENGINE=podman mise run e2e:podman
  → test result: ok. 1 passed (previously failing test now passes).
• macOS, full suite: CONTAINER_ENGINE=podman mise run e2e:podman — the previously
  failing podman_gateway_start now passes. All other Podman test files up to that
  point pass. One unrelated test, provider_refresh_handles::long_running_process_survives_rotations_and_reconfigure_revokes,
  fails on this macOS machine with Error: "initial long-running credential probe failed"
  (sandbox container exits 137). It reproduces in isolation and shares no code with this
  single-file change, so it is a pre-existing, unrelated macOS-environment failure; cargo's
  fail-fast then skips the remaining files. It is out of scope for this fix.
• Linux: unchanged by construction — when OPENSHELL_PODMAN_SOCKET is set the test now
  targets that exact socket (the same one the gateway uses); when unset it behaves exactly
  as before.

Checklist

• Scoped strictly to the e2e test harness; no product code changed.
• Conventional Commit, signed off (DCO).
• mise run pre-commit passed.
• Previously failing macOS test now passes; Linux path unchanged.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[johntmyers]

/ok to test ce61ccf