feat(kora-deploy): add resume capability and buffer cleanup on transient failures

[raushan728]

Adds resume capability and automatic buffer cleanup to kora-deploy, persisting local state so deployments can recover from transient failures instead of leaving orphaned on-chain buffers.

• Resume interrupted deployments with --resume, guarded by SHA-256 hash verification and chunk bounds checking
• Buffers are closed automatically on failure by default; pass --no-cleanup-on-failure to leave the buffer open for a later --resume
• Detect already-succeeded deploys after a timeout by checking ProgramData before resubmitting, skipping this check entirely on fresh (non-resume) deploys
• Force buffer cleanup when the initial state save fails, since the buffer can't be recovered any other way in that case
• Refactor deploy() into smaller functions with a shared, parametrized cleanup_buffer! macro
• Add .kora-deploy-state.json to .gitignore since it contains raw keypair bytes
• Add share_mode(0) on the non-Unix save path as a partial mitigation (concurrency guard only, not an ACL restriction full Windows permission support is out of scope here)
• Add unit tests for the state-invariant checks (hash mismatch, chunk-count overflow) via a standalone check_state_invariants() helper
• Document the resume/recovery flow and new flags in the README

[greptile-apps]

Greptile Summary

This PR adds resume capability and automatic buffer cleanup to kora-deploy, persisting deployment state in .kora-deploy-state.json so interrupted deploys can recover without permanently orphaning on-chain buffers. The refactoring of deploy() into load_or_init_state / validate_state / write_chunks / finalize_deploy significantly improves correctness: hash verification catches silent binary changes, cleanup_buffer! is called consistently on every failure path, and the is_already_live programdata check handles the timeout-but-success scenario on resume.

• The state.rs file correctly uses mode(0o600) and an atomic rename for safe writes, adding SHA-256 identity tracking to the persisted state.
• main.rs uses clap's overrides_with mutual exclusion to wire --no-cleanup-on-failure cleanly, with cleanup_on_failure: !args.no_cleanup_on_failure correctly defaulting to true.

Confidence Score: 5/5

• This PR is safe to merge. The deploy/resume logic is substantially more robust than the prior single-function implementation, and the remaining observations are cosmetic or edge-case quality improvements.
• The refactoring addresses a comprehensive set of failure modes: every error path that can leave an orphaned on-chain buffer now calls cleanup_buffer!, the is_already_live programdata check handles the timeout-but-success scenario, and the state file is guarded against accidental overwrites. The two remaining issues are minor: an orphaned .tmp file (protected by 0o600 on Unix) and a misleading "Deployed via..." stdout message when a resume finds the program already live.
• No files require special attention; crates/kora-deploy/src/state.rs and crates/kora-deploy/src/lib.rs are the most complex changed files and are worth a second read, but no blocking issues were found.

Important Files Changed

Filename	Overview
crates/kora-deploy/src/lib.rs	Core deploy logic refactored into sub-functions with a shared cleanup_buffer! macro; addresses most previously flagged state-management issues; two minor UX concerns remain (misleading output on already-live resume, orphaned temp file).
crates/kora-deploy/src/state.rs	New file handling atomic state persistence with proper Unix permissions (0o600) and acknowledged Windows limitation; temp file not cleaned up on rename failure leaves keypair bytes on disk.
crates/kora-deploy/src/main.rs	Adds --resume and --no-cleanup-on-failure flags using clap overrides_with mutual exclusion; default cleanup_on_failure=true is correctly derived from !args.no_cleanup_on_failure.
crates/kora-deploy/README.md	Documents the resume/recovery flow, new flags, and manual recovery steps clearly.
examples/devnet-deploy-paymaster/src/suite/happy.rs	Updated to pass the three new DeployConfig fields with sensible defaults for an automated test.
.gitignore	Correctly excludes the state file from version control with an explanatory comment.

_{Reviews (29): Last reviewed commit: "fix(deploy): update devnet-deploy-paymas..." | Re-trigger Greptile}

[dev-jodee]

• should .gitignore .kora-deploy-state.json
• should prob have tests for hash-mismatch detection, written_chunks > chunk_count corruption handling, skip-already-written-chunks, is_already_live short-circuit, etc.

[raushan728]

• should .gitignore .kora-deploy-state.json

Added

• should prob have tests for hash-mismatch detection, written_chunks > chunk_count corruption handling, skip-already-written-chunks, is_already_live short-circuit, etc.

Added pure-logic unit tests for the two state-invariant checks

For the remaining cases you mentioned (skip-already-written-chunks, is_already_live short-circuit) agreed these need coverage too, but they're integration-style paths that depend on RPC/network calls (Kora + Solana RPC), which this crate doesn't currently have mocking infra for.

Rather than bolting on ad-hoc mocks in an already-large PR, we can file a follow-up issue to properly set up mock-based integration testing for kora-deploy. I'll scope that issue to cover both the integration tests AND adding a Windows CI target, since the non-Unix file-permission gap (raised above) would benefit from actually being exercised in CI rather than just reviewed by eye. That way both gaps get closed together with proper CI coverage backing them, instead of being two separate half-measures.

[raushan728]

Addresses in 87743c2

[dev-jodee]

all looks good except the 1 nit

[dev-jodee]

@raushan728 some CI failures

[raushan728]

@raushan728 some CI failures

Fixed in eb5cc90