fix(runtime): bind-mount file secrets to target paths in Apple container runtime

[ryancee]

Problem

The Apple container runtime was staging file secrets on the host via writeFileSecrets() but discarding the returned mount specs. Instead of bind-mounting each secret to its intended container target path, it was mounting the entire secrets staging directory at /run/scion-secrets:ro.

This meant a secret like OPENCODE_AUTH (target: ~/.local/share/opencode/auth.json) would land at /run/scion-secrets/OPENCODE_AUTH inside the container but not at its actual target path, so any harness relying on the file would silently fail to find it.

Fix

Capture the []string mount specs returned by writeFileSecrets() and pass them to insertVolumeFlags(), so each file secret is bind-mounted directly to its container target path. This mirrors how DockerRuntime.Run() already handles file secrets.

Also disables MetadataInterception for the Apple runtime since it does not support --cap-add NET_ADMIN (required by the iptables-based GCE metadata blocking approach).

Testing

Manually verified on macOS with the Apple Virtualization Framework (container CLI) runtime: OPENCODE_AUTH file secret is now correctly projected to ~/.local/share/opencode/auth.json inside the container.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request refactors secret mounting in the Apple container runtime by utilizing mount specifications returned from writeFileSecrets and removes unused imports. It also disables metadata interception to avoid unsupported Linux capabilities. Feedback suggests that while the code comments mention a reliance on the GCE_METADATA_HOST environment variable for metadata interception, the implementation fails to actually set this variable in the configuration.

[gemini-code-assist]

The comment mentions that metadata interception relies on the GCE_METADATA_HOST environment variable instead of iptables. However, the code only disables MetadataInterception (to avoid the unsupported --cap-add NET_ADMIN flag) but does not appear to set the GCE_METADATA_HOST variable. If the runtime is expected to provide this alternative interception mechanism, consider injecting the environment variable into config.Env here.

[ryancee]

Good catch. GCE_METADATA_HOST and GCE_METADATA_ROOT are already injected into the agent env by the broker (runtimebroker/start_context.go) when in assign/block metadata modes — no need to set them here. The original comment was just misleading. Updated it in 68a1bfc to accurately describe the trade-off: iptables interception is unavailable on Apple, so only apps honouring the standard env vars will reach the scion metadata server; apps that hardcode metadata.google.internal won't be intercepted.