fix(build): guide users when zig is missing

[LosEcher]

Problem

When zig is not installed (or not on PATH and ZIG is unset), the libghostty-vt build script panics with a bare NotFound error that gives no hint about what to install:

thread 'main' panicked at build.rs:77:10:
failed to execute zig build for vendored libghostty-vt: Os { code: 2, kind: NotFound, message: "No such file or directory" }

Fix

build.rs now distinguishes ErrorKind::NotFound and reports:

• that Zig 0.15.2 is required to build the vendored libghostty-vt,
• how to install it (brew install zig@0.15 on macOS, https://ziglang.org/download/ elsewhere),
• that the ZIG environment variable can point at the zig binary.

Other execution errors keep the previous message with the underlying error appended.

Validation

• cargo build (with a working zig 0.15.2) succeeds.
• Without zig on PATH: build now fails with the descriptive message above.
• cargo fmt --check, cargo clippy --all-targets --locked -- -D warnings, maintenance script tests, and cargo nextest run (3030 tests) all pass locally.

Note: on this machine one plugins test initially failed due to a sandboxed home directory (~/.config / ~/.local/state not writable); with XDG_CONFIG_HOME/XDG_STATE_HOME pointed at a writable cache dir the full suite passes. CI on master is green.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f749c136-afdc-4472-ba09-400fc515ae02

📥 Commits

Reviewing files that changed from the base of the PR and between adb50cb and 42dfae8.

📒 Files selected for processing (1)

• build.rs

---

📝 Walkthrough

Walkthrough

The build script now borrows the Zig executable path when creating the command. It also reports separate diagnostics for missing Zig executables and other process-launch failures.

Changes

Zig build handling

Layer / File(s)	Summary
Command launch and diagnostics build.rs	The Zig command borrows the executable path. Process-launch errors now distinguish a missing executable from other execution errors.

Estimated code review effort: 2 (Simple) | ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the build error guidance added when Zig is missing.
Description check	✅ Passed	The description directly explains the missing-Zig problem, the implemented fix, and the validation performed.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

The PR improves the vendored libghostty-vt build failure when Zig cannot be found.

• Preserves the configured Zig executable string for diagnostic output.
• Converts ErrorKind::NotFound into an actionable message naming the required Zig release, installation options, and the ZIG override.
• Retains the underlying error for other process-launch failures.

Confidence Score: 5/5

The PR appears safe to merge, with no actionable defect identified in the changed build-script error handling.

The new branch accurately handles the normal missing executable and invalid ZIG-path cases, while non-NotFound launch errors and nonzero Zig exit statuses retain their existing failure paths.

Important Files Changed

Filename	Overview
build.rs	Adds a targeted, actionable missing-Zig diagnostic while preserving existing behavior for other launch errors and unsuccessful Zig builds.

_{Reviews (1): Last reviewed commit: "fix(build): guide users when zig is miss..." | Re-trigger Greptile}

[LosEcher]

The failing check is check (macos-latest): it failed on api::server::pane_graphics_stream::tests::inactive_owner_cancels_idle_stream_and_dispatches_close with canceled idle stream should dispatch a close: Timeout.

This is an async timeout test in the pane graphics stream — unrelated to this build.rs change (which only alters the error message emitted when the zig executable cannot be found; the happy-path build command is unchanged). Locally the full suite passes (3030/3030). Could a maintainer re-run the macOS job to confirm it is a flake? I can't re-run it as an external contributor.