Cover warp_tui's opt-in features (voice_input, etc.) in presubmit and CI clippy

[warp-agent-staging]

Description

Follow-up to #15570 (a TUI release-blocking E0061 that a green PR introduced, because nothing in presubmit or CI ever compiled warp_tui's opt-in features). This adds the missing coverage so a similar mismatch fails locally and in CI, not just in the scheduled release workflow.

crates/warp_tui's four opt-in features — voice_input, release_bundle, standalone, crash_reporting — are never activated by either script/presubmit or the lints job in .github/workflows/ci.yml. Both run cargo clippy -p warp --all-targets --tests (workspace feature unification pulls in warp_tui with warp/tui, but with warp_tui's own default — empty — feature set), and the workspace-wide --all-features flag is disabled behind a TODO(vorporeal) comment. voice_input.rs's mod voice_input is declared behind #[cfg(feature = "voice_input")] in crates/warp_tui/src/lib.rs, so it was never type-checked outside the release workflow, which only builds it for the actual TUI binaries.

This adds one scoped invocation, in both places, right beside the existing -p warp line:

cargo clippy -p warp_tui --lib --features voice_input,release_bundle,standalone,crash_reporting -- -D warnings

(--locked in CI, to match the surrounding lines there.)

Why not --all-targets --all-features, as originally proposed

I verified both flags before using them and neither works here:

• --all-targets pulls in every warp_tui bin (warp-tui, warp-tui-dev, warp-tui-preview, warp-tui-stable, besides warp-tui-oss). All but warp-tui-oss call warp_channel_config::load_config!("<channel>"), which needs a JSON file only the private warp-channel-config repo generates. Per AGENTS.md, this is exactly why the OSS bin is the default-run — it's the only one that builds without that generator. Neither script/presubmit nor the lints job (unlike the internal release workflow) has access to it, so --all-targets fails here regardless of this fix. I scoped the new check to --lib, which is where the actual regression lived (the mod voice_input declaration, not any bin), so it stays fully decoupled from channel-specific bins.
• --all-features additionally turns on test-util. warp_tui's [dev-dependencies] warp entry pins features = ["tui", "test-util"], which enables warp/test-util → warp_terminal/test-util → warpui_core/test-util — the flag that gates warpui_core::platform::Delegate's get_cursor_shape() method. But every impl of that method (crates/warpui/src/platform/{headless,mac}/delegate.rs, crates/warpui/src/windowing/winit/delegate.rs) is gated on warpui's own, separately-declared test-util feature, and warpui's test-util = ["warpui_core/test-util"] only forwards one direction: enabling it turns on warpui_core/test-util too, but the reverse doesn't hold. Nothing on the warp_tui → warp → warp_terminal → warpui_core chain enables warpui/test-util, so the trait requires the method while every impl of it stays compiled out — a feature-wiring mismatch between warpui_core and warpui, not a missing implementation, and not platform-specific: the same combination would break the mac impl too. (app's own tests don't hit this because its [dev-dependencies] separately pin warpui = { features = ["test-util"] } directly — a path warp_tui never takes.) I did not fix that pre-existing wiring gap here — it belongs in its own change to crates/warpui/warpui_core. I instead named the four real, shipped features explicitly, matching script/macos/bundle's WARP_TUI_FEATURES for the TUI artifact, and left test-util out.

Linked Issue

No tracked issue — a direct follow-up requested in Slack after #15570, asking how to make sure this class of break is caught in presubmit and CI.

Testing

• Per-OS verification:
  • Linux (this sandbox): cargo clippy --locked -p warp_tui --lib --features voice_input,release_bundle,standalone,crash_reporting -- -D warnings compiles cleanly (with Fix warp_tui compile error: thread RequestTeamScope through TUI voice transcription #15570's fix applied — see below). ALSA (cpal's Linux backend, needed by voice_input) is already installed unconditionally by script/linux/install_build_deps (libasound2-dev), for every target_os == linux invocation of prepare_environment, not just release builds — confirmed by reading the script, and by this sandbox's own successful build.
  • Windows: I could not execute this directly, but verified by inspection that it should work: crash_reporting (the feature closest to the workspace-wide pprof/Windows exclusion) forwards to sentry/sentry-log/minidumper/crash-handler, none of which pull in pprof or jemalloc — those are gated by unrelated app features (jemalloc_pprof, heap_usage_tracking) that this change never touches. cpal (voice_input's audio dependency) selects its Windows backend internally with no extra system packages, the same way it already does for the shipped Windows TUI release binary. I did not gate the new step per-OS, since I found no OS-specific incompatibility with these four features.
  • macOS: not directly executed either, but this is the platform the original break was reported on (Build Release Binary (macOS TUI x86_64)), and --features voice_input,release_bundle,standalone,crash_reporting is exactly script/macos/bundle's WARP_TUI_FEATURES for non-oss channels, so this is the best-covered platform by construction.
• Revert-and-fail proof: when this branch was written it sat on an origin/master that did not yet contain Fix warp_tui compile error: thread RequestTeamScope through TUI voice transcription #15570's fix, so no manual revert was needed — the bug was still there. Running the new command against that master failed with exactly the original error:

  error[E0061]: this method takes 3 arguments but 2 arguments were supplied
     --> crates/warp_tui/src/voice_input.rs:324:38
  

  I then cherry-picked Fix warp_tui compile error: thread RequestTeamScope through TUI voice transcription #15570's fix commit locally (uncommitted, not part of this branch) and reran the identical command: it passed. Fix warp_tui compile error: thread RequestTeamScope through TUI voice transcription #15570 has since merged (43de7e46b) and this branch has been rebased onto it, so the guard now runs against a master that contains the fix and CI is expected to be green. That sequence is itself the proof: the same command failed before the fix landed and passes after it.
• Added compile time: cleaning only the warp/warp_tui build artifacts (dependencies stay cached) and rerunning the new command took ~1m40s (failing) / ~1m44s (passing). This runs once per lints matrix job (3x: macOS/Linux/Windows), alongside the pre-existing -p warp invocation it sits next to.
• ./script/format — no changes needed.

Possible follow-up (not done here)

An alternative, structural fix floated in the original discussion: gate only the mic-capture backend behind voice_input, so the Transcriber/transcribe() call site itself always compiles regardless of the feature. That's a real option and would remove the need for this kind of explicit feature list entirely, but it's a behavior change to crates/warp_tui/src/voice_input.rs's structure, not a CI-coverage change, so it belongs in its own PR.

Agent Mode

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

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.