Default session storage is world-readable in Strands Agents

There is a local confidentiality issue in the default `FileSessionManager` storage behavior. By default it writes session data under `/tmp/strands/sessions` and relies on the process umask for directory and file permissions. On systems using the common `umask 022`, the session directories are `0755` and JSON files are `0644`, so other local users can read persisted agent session data. This matters on shared developer machines, CI hosts, notebooks, jump boxes, and multi-user GPU servers. Session storage is intended to persist conversation/history/state, so it can contain prompts, model output, tool inputs/outputs, intermediate state, and secrets that pass through the agent. Relevant code: - `strands-py/src/strands/session/file_session_manager.py:58`: default storage path is `os.path.join(tempfile.gettempdir(), "strands/sessions")`. - `strands-py/src/strands/session/file_session_manager.py:118`: creates parent directories without a private mode. - `strands-py/src/strands/session/file_session_manager.py:121`: writes JSON files via normal `open(..., "w")`. - `strands-py/src/strands/session/file_session_manager.py:131`: creates session directories without a private mode. Local reproduction with `umask 022`: ```text default_storage_dir= /tmp/strands/sessions 0o755 /tmp/strands/sessions 0o755 /tmp/strands/sessions/session_codex_perm_poc 0o644 /tmp/strands/sessions/session_codex_perm_poc/session.json file_contains_secret= True ``` The fixture wrote a fake secret into the session dict to show that sensitive session fields are readable through the resulting file. Suggested fixes: - Use a private per-user data directory by default rather than `/tmp`, or create `/tmp/strands` and descendants with `0700`. - Write session JSON atomically with `0600` permissions. - Consider refusing to use an existing default storage directory if it is not owned by the current user or is group/world accessible. - Document that callers should set `storage_dir` explicitly when they need shared storage. This was reproduced on commit `dd7b41de38cb`.