Create config and cache files with 0600 permissions

[fnando]

What

Centralize hardened-permission file writes through a new locator::write_hardened_file helper, and migrate every config/cache writer to use it. On Unix the helper opens with OpenOptions + mode(0o600) and calls set_hardened_permissions afterwards; on non-Unix it falls back to std::fs::write.

Migrated writers: KeyType::write, UpgradeCheck::save, Config::save_to, data::write, data::write_spec, save_contract_id, remove_contract_id, and tx edit's scratch file. For snapshot create's two streaming bucket downloads (which can't take a byte slice) added a set_hardened_permissions call after each fs::rename. User-owned destinations (--out, --out-file, WASM build artifacts) are intentionally left alone.

Closes #2562.

Why

UpgradeCheck::save wrote upgrade_check.json with plain fs::write, so on first creation the file landed at the umask default (typically 0644). Because the upgrade check runs in the background on every CLI invocation, the next run's ensure_directory sweep walked the tree, fixed the perms, and printed ⚠️ Updated config files permissions to 0600. to users who had not run any write-style command. The same shape existed in several other writers (Config::save_to, data::write/write_spec, etc.) and was being papered over by fix_config_permissions after the fact. Going through one helper closes the bug class instead of just the reported instance.

Known limitations

• Streaming bucket downloads in snapshot create have a brief window between rename and chmod where the file exists at the umask-default mode. Acceptable since the contents are public ledger data, not secrets.
• set_hardened_permissions errors after the streaming downloads are intentionally swallowed, matching the soft-failure behavior already used by fix_config_permissions.

[Copilot]

Pull request overview

This PR centralizes hardened-permission writes into a single config::locator::write_hardened_file helper and migrates several config/cache writers to use it, ensuring newly created files land with 0600 permissions on Unix (instead of relying on umask defaults). This directly addresses the reported issue where the background upgrade-check would create upgrade_check.json with relaxed permissions and trigger a subsequent “updated permissions” warning on the next run.

Changes:

• Added locator::write_hardened_file and updated multiple writers to use it instead of plain fs::write / manual OpenOptions handling.
• Added a Unix-only regression test asserting upgrade_check.json is created with 0600 permissions.
• After streaming downloads in snapshot create, applies set_hardened_permissions post-rename (best-effort) to harden the final cached file.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
cmd/soroban-cli/src/config/upgrade_check.rs	Uses write_hardened_file for saving; adds Unix permission regression test for 0600.
cmd/soroban-cli/src/config/mod.rs	Switches Config::save_to to write_hardened_file after ensure_directory.
cmd/soroban-cli/src/config/locator.rs	Introduces write_hardened_file helper and migrates existing writers to it.
cmd/soroban-cli/src/config/data.rs	Writes actionlog/spec cache artifacts via write_hardened_file.
cmd/soroban-cli/src/commands/tx/edit.rs	Writes the editor scratch file via write_hardened_file (while keeping tempdir 0700 on Unix).
cmd/soroban-cli/src/commands/snapshot/create.rs	Applies set_hardened_permissions to cached downloads after rename (best-effort).