Fix >4GiB log bundle exports and harden create_log_bundle_zip (APP-5496)

[warp-agent-staging]

Description

Fixes APP-5496 in warp_logging::imp::create_log_bundle_zip (crates/warp_logging/src/native.rs), the function behind "View Warp logs" (Help menu) and the Warp Agent CLI's /view-logs command:

• >4 GiB entries broke the whole bundle. LogConfig::max_file_size_bytes defaults to None in production, so a long, verbose session's warp.log can exceed 4 GiB. SimpleFileOptions::default() left large_file: false, so ZipWriter aborted the entry once it crossed ZIP64_BYTES_THR with "Large file option has not been set". Fixed by deciding large_file per entry from the source file's metadata length (with a margin below the raw threshold, since the active log can still be growing mid-copy and zip separately checks compressed size against the same threshold), so oversized entries use ZIP64 while small entries stay in the more widely-compatible non-ZIP64 format.
• Unused zip codecs/dependency surface. This path only ever writes CompressionMethod::Deflated, but the crate pulled in zip's full default feature set (bzip2, lzma, xz, zstd, aes-crypto, deflate64, and the zopfli DEFLATE backend). Trimmed to default-features = false with only deflate-flate2 (+ flate2's rust_backend, the backend that feature needs but doesn't select on its own). Caveat, left for the reviewer to weigh in on: crates/node_runtime (pulled into the app/GUI binary transitively via crates/lsp) also depends on zip with full default features, and Cargo unifies package features across a build's whole dependency graph — confirmed the shipped app binary links both. So this trim is the correct, minimal declaration for warp_logging itself, but doesn't reduce the feature set actually linked into app today.
• Bounded, not merely happens-to-be-bounded, copy loop. The existing std::io::copy call was already O(1) in input size; left a one-line comment so a future change doesn't turn it into a full in-memory buffer.
• Concurrent/repeated export requests. Added an in-flight AtomicBool guard (RAII-released, so a failed or panicking export doesn't wedge future ones) so a second concurrent request in the same process fails fast with "A log bundle export is already in progress" rather than racing a second archive build over the same files. Didn't touch either caller: the GUI toast already interpolates {err} and will show this text; the TUI hint (crates/warp_tui/src/terminal_session_view.rs:4601) renders a fixed LOG_BUNDLE_FAILED_HINT string, so this specific message won't reach a Warp Agent CLI user today — whether to plumb it through is part of the requester's call.
• Failure-path cleanup. A failed export no longer leaves an orphaned partial .zip behind, and I/O errors now name the file that failed rather than surfacing a bare OS error.

I also measured whether this function can actually produce the ~8 GB live-heap growth Sentry's profile attributed to zip::write::GenericZipWriter::switch_to: peak RSS stayed flat (~4.5 MB) across 150 MB and 6 GiB of input in this single-threaded, sequential-entry loop, so that leak does not reproduce here; recorded on the Linear ticket, and the fixes above stand on their own regardless.

Two open review threads (inline on this PR) are left for the requester to decide: the in-flight guard's scope/blast radius, and whether the zip feature trim belongs in this PR given the node_runtime caveat above.

Linked Issue

Linear: APP-5496

• Filed by the Sentry memory-triage bot; no ready-to-spec/ready-to-implement GitHub issue exists for this.

Testing

• needs_zip64_respects_margin_below_threshold (new): unit-tests the extracted threshold predicate at its boundary.
• bundle_zip_supports_entries_over_4gib (new, #[ignore]d — writes a real 4 GiB+ entry, ~6-15s and not sparse on Windows/NTFS, so it's excluded from the default cargo nextest run): exercises the >4 GiB path end-to-end and asserts the resulting entry's uncompressed size.
• create_log_bundle_zip_rejects_concurrent_exports_and_recovers_after_failure (new): rejects a concurrent call, and confirms the in-flight guard clears after both a failed and a successful export.
• cargo nextest run -p warp_logging: 26/26 passed (the ignored test verified separately, passing in ~6s).
• ./script/format --check: clean.
• cargo clippy -p warp_logging --all-targets --tests -- -D warnings: clean.
• cargo clippy --workspace --exclude warp_completer --all-targets --tests -- -D warnings: clean.
• cargo clippy -p warp --all-targets --tests -- -D warnings: clean (confirms the app binary, which links both node_runtime and warp_logging, still builds under the trimmed features).
• Not run: full ./script/presubmit (clang-format/wgslfmt/PowerShell lint/full-workspace nextest) — this change only touches crates/warp_logging, and the targeted checks above cover it; the full workspace test suite was not re-run end-to-end due to time/resource constraints in this sandbox.
• I have manually tested my changes locally with ./script/run — not done; this is headless, non-UI logic and the automated tests above exercise the actual code path directly.

Screenshots / Videos

Not applicable — backend-only change, no UI surface.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[warp-agent-staging]

Overview

Selects ZIP64 per entry so log bundles no longer fail once a log passes 4 GiB, and adds a concurrency guard plus a zip feature trim alongside it. The ZIP64 fix is correct, tested, and should land; two of the changes around it need a decision from you.

Concerns

• The in-flight guard is a fix for a different bug, and it reports itself to Sentry. Both call sites funnel the error into report_error! (app/src/workspace/view.rs:6718, crates/warp_tui/src/terminal_session_view.rs:4600), so an ordinary double-click on "View Warp logs" now files a Sentry event — on a ticket that arrived from Sentry noise. The mechanism itself is sound, but the underlying bug is a TOCTOU between zip_path.exists() and File::create at native.rs:516, which File::create_new or a unique suffix would fix in less code and would let the second export succeed instead of refusing.
• The feature trim changes nothing in any build this workspace produces. cargo tree -e features confirms bzip2, lzma, xz, zstd, aes-crypto, deflate64 and deflate-zopfli all stay active because crates/node_runtime (reached from app via crates/lsp) still pulls zip with default features, and the workspace is publish = false, so no external consumer builds warp_logging alone. Keeping it as the correct minimal declaration is defensible; so is deferring it to a PR that also trims node_runtime and can show a binary-size delta.
• CI has never run on this branch. All substantive jobs report skipping while the PR is a draft (.github/workflows/ci.yml:46-51), so every platform claim about the new 4 GiB test is still unvalidated — notably on windows-latest-large, where NTFS does not make set_len sparse and the file reserves 4 GiB of real disk.

Verdict

Checks: build pass, tests pass (26/26 in warp_logging locally), CI not run (draft — all jobs skipped), visual proof n/a (backend-only)

Found: 0 critical, 5 important, 5 suggestions, 3 nits. The two decisions above are yours; the remaining findings (changelog command name, an over-claiming doc comment, a missing success-path assertion, a ZIP64 size round-trip assertion, and the 4 GiB test's CI cost) are being revised now.

Responding as wilson: Open session · View factory task

[warp-agent-staging]

The guard is correct on every path I checked — swap cannot interleave with the let _guard, and the RAII drop fires on all ? early returns. My concern is its blast radius: both callers pass this error to report_error!, so a user double-clicking "View Warp logs" now files a Sentry event, and in the TUI they never even see the reason (terminal_session_view.rs:4601 renders a fixed LOG_BUNDLE_FAILED_HINT). The bug worth fixing here is the TOCTOU at line 516, where two exports in the same second both pass zip_path.exists() and then both File::create the same path; File::create_new or a unique suffix fixes that in less code and lets the second export succeed.

[warp-agent-staging]

The declaration is right, including the non-obvious part: zip pins flate2 with default-features = false, so the separate direct flate2 dependency is genuinely load-bearing for rust_backend. But it reads as an unused direct dependency — please add a comment saying it exists solely to select zip's DEFLATE backend. Separately, this trim has no effect on any binary built here while node_runtime still pulls zip with default features, so it is worth deciding whether it belongs in this PR or in one that trims both and can demonstrate the size delta.