Rootless podman sandbox hit EACCES because --userns=keep-id is not set

### What happened?

I'm running Gemini CLI locally on arch linux with the podman sandbox enabled: `GEMINI_SANDBOX=podman`
When i run npm start, the CLI gets to the point where it rebuilds one of the native dependencies inside the sandbox, but the rebuild fails, i've attached the full output below.

This seems to be related to how the sandbox handles UID/GID mapping with rootless podman.
From what I understand, the current flow creates a user inside the container with the same UID/GID as the host user and then runs Gemini as that user. That works when the container UID maps directly to the host UID, but rootless Podman normally uses a user namespace, so that's not necessarily the case.

Because the project is bind-mounted into the container, this can result in files being owned by a UID that the host user can't modify. In my case, that eventually shows up as `node-gyp` being unable to remove the `build` directory.

### What did you expect to happen?

If the sandbox is using rootless podman and UID/GID mapping is enabled, I would expect the CLI to handle the user namespace mapping automatically so that bind-mounted files remain owned by host user.
something like `podman run --userns=keep-id` should be added automatically for rootless podman, unless the user has already supplied their own --userns option through `SANDBOX_FLAGS`.
This shouldn't change the behaviour for Docker or rootful podman.

### Client information

Client Information
This `/about` is from a local npm start after the keep-id fix. The original `EACCES` was the same nightly (`0.59.0-nightly.20260825.g812f7a2bc`) with `GEMINI_SANDBOX=podman` and no `SANDBOX_FLAGS`

```console
> /about
CLI Version 0.59.0-nightly.20260825.g812f7a2bc
Git Commit 273a493ee
Model Auto
Sandbox sandbox-0.59.0-nightly.20260825.g812f7a2bc-31c6bdb6c789
OS linux
Auth Method gemini-api-key
```

### Login information

using API keys

### Anything else we need to know?

This is closely related to `https://github.com/google-gemini/gemini-cli/issues/15376` where `--userns=keep-id` was suggested as a workaround.
the workaround does fixes the underlying UID mapping problem, but requiring users to manually add a podman specific flag feels like something the CLI could handle itself.

I have a small patch that adds `--userns=keep-id` only when:
- the sandbox is podman
- the host is not running as root
- UID/GID mapping is enabled
- `SANDBOX_FLAGS` does not already contain a `--userns` option

I'll be happy to open a PR if this is something you'd consider fixing in the CLI.

Start with the sandbox entry point selected by GEMINI_SANDBOX=podman and the handling of SANDBOX_FLAGS; reproduce with npm start under rootless Podman and inspect the existing user-namespace behavior. Done means keep-id is added only for rootless Podman when no --userns flag is supplied, without changing Docker or rootful Podman behavior, and the bind-mounted project remains writable.

Written by the indexing model from the issue text.