[BUG] Sandboxed Bash opens every existing sandbox.credentials.files path (4x each) on every command; floods file-access audit logs (macOS)

Environment: Claude Code CLI 2.1.294, macOS 26.7.1 (Intel), sandbox enabled, ~170 entries in sandbox.credentials.files (about 40 exist on disk).

What happens: before each sandboxed Bash command runs, the CLI process itself calls open() on every listed credential file that exists. Measured with an endpoint file-access auditor (Santa File Access Authorization, audit-only), one trivial command (echo) produced 160 open records in 42 ms: 40 distinct files x 4 opens each, all attributed to the Claude Code binary, before the command started. A busy session produces ~10k such records in 5 minutes; the audit log grew 386 MB between two hourly rotations.

Why it matters: credential-file access is a primary intrusion signal for EDR and audit tools. A tool that opens every protected key on every command drowns that signal, and forces either a blanket exemption for the tool (losing visibility of real reads) or log volume that breaks retention.

Expected: denying a path in the sandbox profile shouldn't need open(). If an existence or realpath check is needed, lstat/realpath (no open), once per session, cached.

Repro: list a few existing files in sandbox.credentials.files, watch opens (e.g. sudo fs_usage -w -f filesys | grep <file> or an ES-based auditor), run any sandboxed Bash command.

Related: #95695 (glob expansion cost at session start, Linux).