Rebased on top of #9388 (which landed \`hpp\`, \`hxx\`, and the
uppercase \`H\` form, per @bnavetta's request).

This keeps just the one delta from the original PR: adding \`h++\` to
the match arm so the case list covers the full set of C++ header
conventions, and extending the existing
\`cpp_header_extensions_resolve_to_cpp_language\` test to include
\`header.h++\`.

\`h++\` is the rarer of the C++ header conventions but it's part of the
canonical set (used in some older codebases and called out in the GNU
coding style guidance for C++).

### Testing

- Existing \`cpp_header_extensions_resolve_to_cpp_language\` test
extended to include \`header.h++\`.
- \`cargo fmt -p languages -- --check\` passes.
- \`cargo test -p languages\` doesn't run locally for me (Metal
toolchain unavailable on this machine — same situation as #9277), but CI
should cover it.

### Server API

No server changes.

### Agent Mode

Not applicable.

### Changelog Entries

\`CHANGELOG-IMPROVEMENT\`: Recognize \`.h++\` files as C++ headers (in
addition to \`.hpp\`, \`.hxx\`, and \`.H\` from #9388).

Co-authored-by: anshul-garg27 <[email protected]>

## Description

`extension_for_content_type` in `app/src/ai/artifact_download.rs` only
mapped `image/jpeg` to a `.jpg` extension, but two adjacent code paths
already treat `image/jpg` (the non-standard alias still emitted by some
tools and CDNs) as an equivalent JPEG type:

- `app/src/util/image.rs:29` — `SUPPORTED_IMAGE_MIME_TYPES` lists both
`image/jpeg` and `image/jpg`.
- `app/src/terminal/input.rs:10044` — the paste-image handler matches
`\"image/jpeg\" | \"image/jpg\" => \"jpg\"`.

So an artifact served with `Content-Type: image/jpg` would pass the
supported-types check elsewhere in the app but get a missing/wrong
extension when saved through `artifact_download`. This patch lines that
one path up with the rest of the codebase by treating `image/jpg` as an
alias for `image/jpeg`, and adds a unit test that pins both spellings.

## Testing

- Added unit test
`extension_for_content_type_recognizes_image_jpg_alias` covering both
`image/jpg` and `image/jpeg`.
- `cargo fmt -p warp -- --check` ✅
- `cargo nextest` skipped locally — Metal toolchain isn't available on
my machine, same situation as #9277. CI will exercise the test.

## Server API

- [ ] Yes
- [x] No

## Agent Mode

- [ ] Yes
- [x] No

## Changelog Entries

- CHANGELOG-BUG-FIX: Fixed downloaded image artifacts served with
`Content-Type: image/jpg` getting the wrong file extension.

Co-authored-by: anshul-garg27 <[email protected]>

## Description

Fixes #9213. On macOS, `.command` is the standard extension for
double-clickable shell scripts (a `#!/usr/bin/env bash` file you can
`chmod +x` and run from Finder). Opening one in Warp's editor today
shows "Language support is unavailable for this file type" because
`language_by_filename` in `crates/languages/src/lib.rs` doesn't include
`command` next to the existing `sh | zsh | bash` shell extensions.

```diff
-        "sh" | "zsh" | "bash" => language_by_name("shell"),
+        "sh" | "zsh" | "bash" | "command" => language_by_name("shell"),
```

## Testing

- Added `command_extension_resolves_to_shell` in
`crates/languages/src/lib_tests.rs` that calls
`language_by_filename(Path::new("script.command"))` and asserts the
returned language's `display_name` is `"Shell"` — fails on master,
passes after the fix.
- `cargo fmt -p languages -- --check` passes locally.
- Couldn't run `cargo nextest run -p languages` locally because the
Metal toolchain isn't installed (same situation as #9277), so relying on
CI for the full clippy / nextest pass.

## Changelog Entries for Stable

CHANGELOG-BUG-FIX: `.command` shell scripts now open with shell syntax
highlighting in Warp's editor.

Co-authored-by: anshul-garg27 <[email protected]>

## Description

Follow-up to #9395 in a different file. While auditing image-extension
lists across the repo I found a third copy in
`is_supported_blocklist_image_source`
(`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the
exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`,
missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to
local `.bmp` / `.tiff` / `.ico` images in agent block output fail the
support check and don't render as the inline image — they silently fall
back to plain text — even though the same files do route to the system
viewer once #9395 lands.

```diff
-                "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg"
+                "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg"
```

The full picture, for context:

| Location | What it does | Pre-fix |
|---|---|---|
| `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical
binary-file extension list | 9 image formats |
| `app/src/util/openable_file_type.rs` (`is_supported_image_file`) |
Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed
in #9395 |
| **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs`
(`is_supported_blocklist_image_source`) | Gates inline rendering of
agent block image references | 6 formats |
| `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) |
Theme-creator file-picker filter | 3 formats — left for a separate PR;
the right "what should be selectable as a theme background" set is more
subjective |

## Testing

- Added
`is_supported_blocklist_image_source_covers_common_local_formats` in
`common_tests.rs`. Asserts every supported extension passes (10 cases),
case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS
sources and non-image extensions still return false. Fails on master for
the four new extensions, passes after the change.
- `cargo fmt -p warp -- --check` passes locally.
- Couldn't run `cargo nextest` locally because the Metal toolchain isn't
installed (same caveat as #9277, #9345, #9346, #9395) — relying on CI
for the full clippy / nextest pass.

## Related

- #9395 — same fix for `is_supported_image_file` (file-open routing
path).

## Changelog Entries for Stable

CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in
agent block output now render correctly instead of falling back to plain
text.

Co-authored-by: anshul-garg27 <[email protected]>

## Description

Follow-up to warpdotdev#9395 in a different file. While auditing image-extension
lists across the repo I found a third copy in
`is_supported_blocklist_image_source`
(`app/src/ai/blocklist/block/view_impl/common.rs`) that suffers from the
exact same drift: it only matches `jpg | jpeg | png | gif | webp | svg`,
missing `.bmp`, `.tiff` / `.tif`, and `.ico`. So inline references to
local `.bmp` / `.tiff` / `.ico` images in agent block output fail the
support check and don't render as the inline image — they silently fall
back to plain text — even though the same files do route to the system
viewer once warpdotdev#9395 lands.

```diff
-                "jpg" | "jpeg" | "png" | "gif" | "webp" | "svg"
+                "jpg" | "jpeg" | "png" | "gif" | "bmp" | "tiff" | "tif" | "webp" | "ico" | "svg"
```

The full picture, for context:

| Location | What it does | Pre-fix |
|---|---|---|
| `crates/warp_util/src/file_type.rs` (`is_binary_file`) | Canonical
binary-file extension list | 9 image formats |
| `app/src/util/openable_file_type.rs` (`is_supported_image_file`) |
Routes click-to-open to `FileTarget::SystemGeneric` | 6 formats — fixed
in warpdotdev#9395 |
| **This PR** — `app/src/ai/blocklist/block/view_impl/common.rs`
(`is_supported_blocklist_image_source`) | Gates inline rendering of
agent block image references | 6 formats |
| `crates/warpui_core/src/platform/file_picker.rs` (`FileType::Image`) |
Theme-creator file-picker filter | 3 formats — left for a separate PR;
the right "what should be selectable as a theme background" set is more
subjective |

## Testing

- Added
`is_supported_blocklist_image_source_covers_common_local_formats` in
`common_tests.rs`. Asserts every supported extension passes (10 cases),
case-insensitivity (`PHOTO.PNG`, `scan.TIFF`), and that HTTP / HTTPS
sources and non-image extensions still return false. Fails on master for
the four new extensions, passes after the change.
- `cargo fmt -p warp -- --check` passes locally.
- Couldn't run `cargo nextest` locally because the Metal toolchain isn't
installed (same caveat as warpdotdev#9277, warpdotdev#9345, warpdotdev#9346, warpdotdev#9395) — relying on CI
for the full clippy / nextest pass.

## Related

- warpdotdev#9395 — same fix for `is_supported_image_file` (file-open routing
path).

## Changelog Entries for Stable

CHANGELOG-BUG-FIX: Inline `.bmp`, `.tiff` / `.tif`, and `.ico` images in
agent block output now render correctly instead of falling back to plain
text.

Co-authored-by: anshul-garg27 <[email protected]>

Rebased on top of warpdotdev#9388 (which landed \`hpp\`, \`hxx\`, and the
uppercase \`H\` form, per @bnavetta's request).

This keeps just the one delta from the original PR: adding \`h++\` to
the match arm so the case list covers the full set of C++ header
conventions, and extending the existing
\`cpp_header_extensions_resolve_to_cpp_language\` test to include
\`header.h++\`.

\`h++\` is the rarer of the C++ header conventions but it's part of the
canonical set (used in some older codebases and called out in the GNU
coding style guidance for C++).

### Testing

- Existing \`cpp_header_extensions_resolve_to_cpp_language\` test
extended to include \`header.h++\`.
- \`cargo fmt -p languages -- --check\` passes.
- \`cargo test -p languages\` doesn't run locally for me (Metal
toolchain unavailable on this machine — same situation as warpdotdev#9277), but CI
should cover it.

### Server API

No server changes.

### Agent Mode

Not applicable.

### Changelog Entries

\`CHANGELOG-IMPROVEMENT\`: Recognize \`.h++\` files as C++ headers (in
addition to \`.hpp\`, \`.hxx\`, and \`.H\` from warpdotdev#9388).

Co-authored-by: anshul-garg27 <[email protected]>

…tdev#9603)

## Description

`extension_for_content_type` in `app/src/ai/artifact_download.rs` only
mapped `image/jpeg` to a `.jpg` extension, but two adjacent code paths
already treat `image/jpg` (the non-standard alias still emitted by some
tools and CDNs) as an equivalent JPEG type:

- `app/src/util/image.rs:29` — `SUPPORTED_IMAGE_MIME_TYPES` lists both
`image/jpeg` and `image/jpg`.
- `app/src/terminal/input.rs:10044` — the paste-image handler matches
`\"image/jpeg\" | \"image/jpg\" => \"jpg\"`.

So an artifact served with `Content-Type: image/jpg` would pass the
supported-types check elsewhere in the app but get a missing/wrong
extension when saved through `artifact_download`. This patch lines that
one path up with the rest of the codebase by treating `image/jpg` as an
alias for `image/jpeg`, and adds a unit test that pins both spellings.

## Testing

- Added unit test
`extension_for_content_type_recognizes_image_jpg_alias` covering both
`image/jpg` and `image/jpeg`.
- `cargo fmt -p warp -- --check` ✅
- `cargo nextest` skipped locally — Metal toolchain isn't available on
my machine, same situation as warpdotdev#9277. CI will exercise the test.

## Server API

- [ ] Yes
- [x] No

## Agent Mode

- [ ] Yes
- [x] No

## Changelog Entries

- CHANGELOG-BUG-FIX: Fixed downloaded image artifacts served with
`Content-Type: image/jpg` getting the wrong file extension.

Co-authored-by: anshul-garg27 <[email protected]>

## Description

Fixes warpdotdev#9213. On macOS, `.command` is the standard extension for
double-clickable shell scripts (a `#!/usr/bin/env bash` file you can
`chmod +x` and run from Finder). Opening one in Warp's editor today
shows "Language support is unavailable for this file type" because
`language_by_filename` in `crates/languages/src/lib.rs` doesn't include
`command` next to the existing `sh | zsh | bash` shell extensions.

```diff
-        "sh" | "zsh" | "bash" => language_by_name("shell"),
+        "sh" | "zsh" | "bash" | "command" => language_by_name("shell"),
```

## Testing

- Added `command_extension_resolves_to_shell` in
`crates/languages/src/lib_tests.rs` that calls
`language_by_filename(Path::new("script.command"))` and asserts the
returned language's `display_name` is `"Shell"` — fails on master,
passes after the fix.
- `cargo fmt -p languages -- --check` passes locally.
- Couldn't run `cargo nextest run -p languages` locally because the
Metal toolchain isn't installed (same situation as warpdotdev#9277), so relying on
CI for the full clippy / nextest pass.

## Changelog Entries for Stable

CHANGELOG-BUG-FIX: `.command` shell scripts now open with shell syntax
highlighting in Warp's editor.

Co-authored-by: anshul-garg27 <[email protected]>

Closes #9196.

### Description

Two `show_code_review_button` gates were dropping panel-open requests on
the floor when the user had hidden the toolbar button:

**1. Data-path gate at `Workspace::setup_code_review_panel`
(`view.rs:7982`)**

```rust
if !*TabSettings::as_ref(ctx).show_code_review_button {
    return;
}
```

`update_right_panel_open_state` calls into this whenever the right panel
is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the
early return silently swallowed every explicit user action.

**2. Render-path gate at `Workspace::render_config_panel` and
`render_config_panel_maximized` (`view.rs:18981` / `19040`)**

```rust
if !item.is_available(app) || !item.is_panel() { return None; }
…
if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; }
```

`HeaderToolbarItemKind::is_available` for `CodeReview` returns
`*TabSettings::as_ref(app).show_code_review_button.value()`
(`header_toolbar_item.rs:89`). So even after fix #1 set
`pane_group.right_panel_open = true` and `setup_code_review_panel` ran,
the next render frame saw `is_available() == false` and returned `None`
— the `right_panel_view` was never added to the layout.

This second gate is what @moirahuang flagged when their local repro
still showed nothing happening after the first fix landed. The data was
correct; the panel was just never composed into the UI.

### Fix

1. **Drop the early return at `setup_code_review_panel`.** The setting
is meant to gate only the toolbar button's visibility (already enforced
correctly by `header_toolbar_item.rs::is_available`, which feeds
`render_header_toolbar_button` at `view.rs:17276`).
2. **Switch panel-render call sites from `is_available` →
`is_supported`.** `is_available`'s own doc-comment says it's
specifically *"Whether this item should be shown in the **toolbar** —
checks both `is_supported` and user show/hide preferences."* Using it to
gate panel rendering conflates two unrelated concerns. Panel rendering
should only care about whether the feature is compiled in
(`is_supported`), not whether the user has hidden the toolbar button.

For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For
the other variants in the same match (`TabsPanel`, `ToolsPanel`),
`is_available` already equals `is_supported` (default `_ => true` arm in
the inner match), so behaviour is unchanged. `AgentManagement` and
`NotificationsMailbox` return `None` unconditionally inside
`render_config_panel`, so the change is moot for them too.

### Caller audit for `setup_code_review_panel`

5 call sites in `view.rs`:

1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab
already had `right_panel_open == true`.
2. `view.rs:8136` — `update_right_panel_open_state` with `should_open ==
true`. **The diff-button path** that #9196 is about.
3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open`
already true.
4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open`
already true.
5. `view.rs:14458` — session env update, gated on `right_panel_open`
already true.

None of these need the `show_code_review_button` gate — they're either
explicit user actions or gated on `right_panel_open` already being open.
The toolbar button toggle continues to do its job at
`render_header_toolbar_button` independently.

### Testing

Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon)
against `WarpOss.app` built from this branch:

1. Settings → "Show code review button" → **OFF**
2. `echo "x" >> README.md` inside a git repo
3. Click the diff stats chip on the prompt (`+1 -0`)

**Result:** Code review panel opens on the right showing the diff, while
the toolbar button stays hidden — exactly the expected behaviour from
issue #9196. Inverse case (toggle ON) also verified: toolbar button
visible, panel still works the same.

- `cargo fmt -p warp -- --check` passes.
- `cargo nextest` skipped locally — Metal toolchain unavailable on my
machine, mirroring #9277. CI will exercise the change.

### Server API

No server changes.

### Agent Mode

Not applicable.

### Changelog Entries

`CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens
the code review panel even when the toolbar's "Show code review button"
toggle is disabled (regression from a recent release).

Co-authored-by: anshul-garg27 <[email protected]>

…v#9600)

Closes warpdotdev#9196.

### Description

Two `show_code_review_button` gates were dropping panel-open requests on
the floor when the user had hidden the toolbar button:

**1. Data-path gate at `Workspace::setup_code_review_panel`
(`view.rs:7982`)**

```rust
if !*TabSettings::as_ref(ctx).show_code_review_button {
    return;
}
```

`update_right_panel_open_state` calls into this whenever the right panel
is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the
early return silently swallowed every explicit user action.

**2. Render-path gate at `Workspace::render_config_panel` and
`render_config_panel_maximized` (`view.rs:18981` / `19040`)**

```rust
if !item.is_available(app) || !item.is_panel() { return None; }
…
if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; }
```

`HeaderToolbarItemKind::is_available` for `CodeReview` returns
`*TabSettings::as_ref(app).show_code_review_button.value()`
(`header_toolbar_item.rs:89`). So even after fix #1 set
`pane_group.right_panel_open = true` and `setup_code_review_panel` ran,
the next render frame saw `is_available() == false` and returned `None`
— the `right_panel_view` was never added to the layout.

This second gate is what @moirahuang flagged when their local repro
still showed nothing happening after the first fix landed. The data was
correct; the panel was just never composed into the UI.

### Fix

1. **Drop the early return at `setup_code_review_panel`.** The setting
is meant to gate only the toolbar button's visibility (already enforced
correctly by `header_toolbar_item.rs::is_available`, which feeds
`render_header_toolbar_button` at `view.rs:17276`).
2. **Switch panel-render call sites from `is_available` →
`is_supported`.** `is_available`'s own doc-comment says it's
specifically *"Whether this item should be shown in the **toolbar** —
checks both `is_supported` and user show/hide preferences."* Using it to
gate panel rendering conflates two unrelated concerns. Panel rendering
should only care about whether the feature is compiled in
(`is_supported`), not whether the user has hidden the toolbar button.

For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For
the other variants in the same match (`TabsPanel`, `ToolsPanel`),
`is_available` already equals `is_supported` (default `_ => true` arm in
the inner match), so behaviour is unchanged. `AgentManagement` and
`NotificationsMailbox` return `None` unconditionally inside
`render_config_panel`, so the change is moot for them too.

### Caller audit for `setup_code_review_panel`

5 call sites in `view.rs`:

1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab
already had `right_panel_open == true`.
2. `view.rs:8136` — `update_right_panel_open_state` with `should_open ==
true`. **The diff-button path** that warpdotdev#9196 is about.
3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open`
already true.
4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open`
already true.
5. `view.rs:14458` — session env update, gated on `right_panel_open`
already true.

None of these need the `show_code_review_button` gate — they're either
explicit user actions or gated on `right_panel_open` already being open.
The toolbar button toggle continues to do its job at
`render_header_toolbar_button` independently.

### Testing

Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon)
against `WarpOss.app` built from this branch:

1. Settings → "Show code review button" → **OFF**
2. `echo "x" >> README.md` inside a git repo
3. Click the diff stats chip on the prompt (`+1 -0`)

**Result:** Code review panel opens on the right showing the diff, while
the toolbar button stays hidden — exactly the expected behaviour from
issue warpdotdev#9196. Inverse case (toggle ON) also verified: toolbar button
visible, panel still works the same.

- `cargo fmt -p warp -- --check` passes.
- `cargo nextest` skipped locally — Metal toolchain unavailable on my
machine, mirroring warpdotdev#9277. CI will exercise the change.

### Server API

No server changes.

### Agent Mode

Not applicable.

### Changelog Entries

`CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens
the code review panel even when the toolbar's "Show code review button"
toggle is disabled (regression from a recent release).

Co-authored-by: anshul-garg27 <[email protected]>

…v#9600)

Closes warpdotdev#9196.

### Description

Two `show_code_review_button` gates were dropping panel-open requests on
the floor when the user had hidden the toolbar button:

**1. Data-path gate at `Workspace::setup_code_review_panel`
(`view.rs:7982`)**

```rust
if !*TabSettings::as_ref(ctx).show_code_review_button {
    return;
}
```

`update_right_panel_open_state` calls into this whenever the right panel
is being opened (chip click, `Shift+Cmd+=` keybinding, etc.), so the
early return silently swallowed every explicit user action.

**2. Render-path gate at `Workspace::render_config_panel` and
`render_config_panel_maximized` (`view.rs:18981` / `19040`)**

```rust
if !item.is_available(app) || !item.is_panel() { return None; }
…
if !HeaderToolbarItemKind::CodeReview.is_available(app) { return None; }
```

`HeaderToolbarItemKind::is_available` for `CodeReview` returns
`*TabSettings::as_ref(app).show_code_review_button.value()`
(`header_toolbar_item.rs:89`). So even after fix warpdotdev#1 set
`pane_group.right_panel_open = true` and `setup_code_review_panel` ran,
the next render frame saw `is_available() == false` and returned `None`
— the `right_panel_view` was never added to the layout.

This second gate is what @moirahuang flagged when their local repro
still showed nothing happening after the first fix landed. The data was
correct; the panel was just never composed into the UI.

### Fix

1. **Drop the early return at `setup_code_review_panel`.** The setting
is meant to gate only the toolbar button's visibility (already enforced
correctly by `header_toolbar_item.rs::is_available`, which feeds
`render_header_toolbar_button` at `view.rs:17276`).
2. **Switch panel-render call sites from `is_available` →
`is_supported`.** `is_available`'s own doc-comment says it's
specifically *"Whether this item should be shown in the **toolbar** —
checks both `is_supported` and user show/hide preferences."* Using it to
gate panel rendering conflates two unrelated concerns. Panel rendering
should only care about whether the feature is compiled in
(`is_supported`), not whether the user has hidden the toolbar button.

For `CodeReview`, `is_supported` is `cfg!(feature = "local_fs")`. For
the other variants in the same match (`TabsPanel`, `ToolsPanel`),
`is_available` already equals `is_supported` (default `_ => true` arm in
the inner match), so behaviour is unchanged. `AgentManagement` and
`NotificationsMailbox` return `None` unconditionally inside
`render_config_panel`, so the change is moot for them too.

### Caller audit for `setup_code_review_panel`

5 call sites in `view.rs`:

1. `view.rs:3681` — `TransferredTab` flow, only runs when the source tab
already had `right_panel_open == true`.
2. `view.rs:8136` — `update_right_panel_open_state` with `should_open ==
true`. **The diff-button path** that warpdotdev#9196 is about.
3. `view.rs:13372` — `PaneFocused` event, gated on `right_panel_open`
already true.
4. `view.rs:13490` — `RepoChanged` event, gated on `right_panel_open`
already true.
5. `view.rs:14458` — session env update, gated on `right_panel_open`
already true.

None of these need the `show_code_review_button` gate — they're either
explicit user actions or gated on `right_panel_open` already being open.
The toolbar button toggle continues to do its job at
`render_header_toolbar_button` independently.

### Testing

Reproduced @moirahuang's test locally on macOS 26.4.1 (Apple Silicon)
against `WarpOss.app` built from this branch:

1. Settings → "Show code review button" → **OFF**
2. `echo "x" >> README.md` inside a git repo
3. Click the diff stats chip on the prompt (`+1 -0`)

**Result:** Code review panel opens on the right showing the diff, while
the toolbar button stays hidden — exactly the expected behaviour from
issue warpdotdev#9196. Inverse case (toggle ON) also verified: toolbar button
visible, panel still works the same.

- `cargo fmt -p warp -- --check` passes.
- `cargo nextest` skipped locally — Metal toolchain unavailable on my
machine, mirroring warpdotdev#9277. CI will exercise the change.

### Server API

No server changes.

### Agent Mode

Not applicable.

### Changelog Entries

`CHANGELOG-BUG-FIX`: The diff button on the terminal prompt now opens
the code review panel even when the toolbar's "Show code review button"
toggle is disabled (regression from a recent release).

Co-authored-by: anshul-garg27 <[email protected]>