File reads, search and attachments hardened against swapped paths

What

Several changes tighten how Claude Code opens and reads files:

• Attachments: in --restricted mode, or when blockReadsOutsideWorkingDirectories is set, the check on attached files now records which path it approved and the file's identity. When the file is opened, Claude Code compares the device and inode numbers (the file's identity on disk) and, on Linux, checks through /proc/self/fd that the open file really is at the approved path. If not, it refuses with errors such as "it opened at a different path than approved". Before, only the device and inode were compared. The documentation changelog lists a related fix: an @-mention under the read block or --restricted could read a file outside the working directories through a link changed mid-read.
• Grep: the search program it runs, ripgrep, is now handed an already-open file through inheritFd instead of a /proc/<pid>/fd/N path, with extra checks on /proc/ paths.
• Directories: a helper that creates directories now creates them with mode: 448, meaning 0700, so only your user can open them.
• Bash: the tool result gains leftRunningPgid when a command leaves its process group (the command and anything it started) still running after a turn.

Why

These close gaps where a file or link could be swapped between the moment Claude Code checks it and the moment it reads it, which matters most in restricted setups. The Bash addition makes it visible when a command leaves processes running in the background.