[Completions] Bump command-signatures to 50fe37c1

[warp-agent-staging]

Description

Bumps the warp-command-signatures git pin in the root Cargo.toml to 50fe37c1, and regenerates Cargo.lock with cargo.

The motivating change is command-signatures#307, which adds the Rust just recipe generator. Until this pin moves, just <TAB> in a Justfile directory still falls back to filesystem path suggestions in the client.

Merged PRs

Relative to the pin currently on master (5e08807c), this newly brings in:

• Complete just completions: Justfile recipe generator (Complete just completions: Justfile recipe generator command-signatures#307)
• Add completion spec: tcpdump (Add completion spec: tcpdump command-signatures#305)

The dependency is pinned by rev in [workspace.dependencies], so moving the rev is the whole change; Cargo.lock was regenerated by cargo (not hand-edited) and its diff is limited to the two source = lines for warp-command-signatures and warp-completion-metadata.

Note on the conflict with #14771

This branch was opened when master pinned 4094b657. #14771 then landed and moved the pin to 5e08807c (openssl), which conflicted here. 5e08807c is a strict ancestor of 50fe37c1 — two commits back on command-signatures:main — so resolving to 50fe37c1 is a fast-forward that loses nothing from #14771; the openssl (#304) and bun (#301) specs it shipped are already included. Verified with git merge-base --is-ancestor 5e08807c 50fe37c1, and independently via gh api repos/warpdotdev/command-signatures/compare/50fe37c...5e08807c → status: behind, behind_by: 2, ahead_by: 0.

master was merged in (not rebased, to preserve the existing approval) and both conflicted files were resolved by taking master's copy and re-applying the newer rev, letting cargo regenerate the lock. The net diff against the new base is unchanged in shape: one Cargo.toml rev line plus the two Cargo.lock source = lines, with no unrelated dependency movement.

Linked Issue

Closes #1906
Tracked in APP-5207.

• The linked issue is labeled ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

This is a dependency-pin bump — testing-exempt under the "dependency/version bump" category, since a test here could only assert the rev string rather than detect a logic defect. The behavior it ships is already covered by the tests added in command-signatures#307 (9 tests over the recipe generator's post-processing, including private-recipe handling and the graceful no-Justfile / no-just paths).

Run locally on this branch, and re-run after merging master in:

• cargo fmt --all --check — clean.
• cargo check -p warp-command-signatures --locked — the new rev resolves and compiles, and --locked confirms Cargo.lock is consistent with the manifest.
• cargo check -p warp_completer --locked and cargo check -p warp --lib --locked — the consumers of the dependency build against the new rev.
• cargo clippy -p warp_completer --all-targets --locked -- -D warnings — clean.
• cargo nextest run -p warp_completer --locked --no-fail-fast — 163 tests: 138 passed, 25 failed, 4 skipped. The 25 failures are pre-existing in this sandbox and unrelated to the bump: they all panic with Tried to check FeatureFlag::CloudEnvironments before feature flags were initialized, and running the identical command on pristine master (this branch with Cargo.toml/Cargo.lock stashed) gives byte-for-byte the same 138 passed, 25 failed, 4 skipped. Net delta from this change is zero.

The full workspace suite was not run locally; CI is the backstop for it.

• I have manually tested my changes locally with ./script/run

Building and running the GUI to TAB-complete a recipe was not possible in this headless environment. The change itself has no rendered surface of its own — it only moves a dependency rev — so there is no UI diff to screenshot beyond the completions menu the merged generator produces.

Agent Mode

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

CHANGELOG-IMPROVEMENT: Added completions for just recipes from your Justfile and for tcpdump.

Originating thread: https://warpdev.slack.com/archives/C0BDQDW8V5E/p1785982310270809

Conversation: https://staging.warp.dev/conversation/e450180d-3523-4c00-8d34-59a96e0edf7f
Run: https://oz.staging.warp.dev/runs/019fd4e0-3937-72e5-9624-4be092502e6f

This PR was generated with Oz.

[warp-agent-staging]

The failing Windows test is a pre-existing flake, not caused by this bump

The one red required check is Run Windows tests, failing solely on warp_tui terminal_session_view::tests::shell_completion_source_warmup_loads_path_executables (crates/warp_tui/src/terminal_session_view_tests.rs:991, assertion failed: session.has_loaded_external_commands()). Evidence that it is unrelated to this diff:

1. The same test fails identically on an unrelated PR.
Run 31061882045 on factory/cloud-followup-routing, roughly two hours before this PR's run, failed its Windows job on exactly the same test and line — and it was that run's only failure:

FAIL + LEAK [   5.511s] (10381/10381) warp_tui terminal_session_view::tests::shell_completion_source_warmup_loads_path_executables
  panicked at crates\warp_tui\src\terminal_session_view_tests.rs:991:9
  Summary [ 179.543s] 10381 tests run: 10380 passed (70 leaky), 1 failed, 47 skipped

That PR touches nothing this one does.

2. The failure is a deadline timeout. The test polls session.has_loaded_external_commands() against a hard Instant::now() + Duration::from_secs(5) deadline. Both failures land right on it — 5.508s here, 5.511s there. On Windows, load_external_commands shells out to enumerate $PATH executables (PowerShell for the Windows-native set), which is slow enough on a loaded runner to overrun 5s.

3. The code path cannot reach this change. load_external_commands runs a shell command and parses executable names out of $PATH; it never consults completion signature data. crates/warp_tui has no dependency on warp-command-signatures at all. This PR changes two lines — a git rev in Cargo.toml and the corresponding source = lines in Cargo.lock — with no source changes.

4. Structurally identical PRs pass. Other warp-command-signatures pin bumps went green on the same Windows job in the same window, e.g. runs 31067008896 and 31065850875.

Also worth noting: the LEAK marker is not a signal here — that Windows run reports 70 leaky tests among the passing ones, so it is ambient on this runner.

Baseline caveat: there is no master run of this job to compare against. The test was added yesterday in #14600 (935f86b9, 2026-08-05), and the most recent Warp CI run on master predates it, so this test has never executed on master's Windows runner. The unrelated-PR failure above is the closest available baseline.

I have rerun the failed job. The 5-second deadline looks too tight for the Windows runner and will likely keep flaking for everyone; worth a separate issue against the test rather than anything in this PR.

Update: the rerun is green — Run Windows tests and Check CI results both passed on the same commit, with no code changes in between. That confirms the flake. The PR is now MERGEABLE / CLEAN with all required checks passing.