refactor(workspace): clarify new-session submenu width constant + apply consistently

[lonexreb]

Description

Menu::with_width() on Menu<A> in app/src/menu.rs:2122 sets the submenu_width field, not the main menu's own rendered width. The constant NEW_SESSION_MENU_WIDTH in app/src/workspace/view.rs:1805 was misleadingly named — setting it does not affect the visible width of the dropdown shown when clicking the tab bar + chevron; only the width of nested submenus (e.g. the Search repos panel that opens off of New worktree config).

This PR:

1. Renames NEW_SESSION_MENU_WIDTH → NEW_SESSION_SUBMENU_WIDTH to accurately describe what the constant drives.
2. Expands the surrounding comment to call out the gotcha (Menu::with_width does not control the main menu's own width) and references the architectural follow-up (adding a min_width to Menu and plumbing it through SubMenu::render / the wrapping ConstrainedBox).
3. Applies .with_width(NEW_SESSION_SUBMENU_WIDTH) to the non-ShellSelector else branch as well, so submenus are 300 px wide regardless of feature flag state. Previously the else branch fell back to DEFAULT_WIDTH = 186 from Menu::new(), producing a noticeably narrower submenu in OSS builds.

Linked Issue

Refs #10269 — this PR explicitly does not close that issue. The visible New worktree config label clipping reported there lives in the main menu's own (content-sized) width, not the submenu width. Fixing it requires the Menu API enhancement described in the updated comment. I started down that path and confirmed the layout pipeline (ConstrainedBox::with_width + SubMenu::render's outer wrapping) doesn't currently expose a hook for the main menu to honor a minimum width — that's a larger architectural change worth its own PR.

• The linked issue is labeled ready-to-spec or ready-to-implement.

Testing

• cargo check --bin warp-oss --features gui — clean
• cargo test -p warp --lib test_unified_new_session_menu — passes (existing tests for menu item presence/order still green; this change touches only the width constant and its application, not menu items themselves)
• Manual GUI verification on macOS: built locally, opened the tab bar + chevron, opened the Search repos submenu off New worktree config. Submenu width is now consistent at 300 px in both the ShellSelector-on and ShellSelector-off paths.

Why no new unit test

The rename is a no-op for tests (the constant's value is unchanged for the ShellSelector-on path). The else-branch width application is a UI dimension change with the same testability constraints as the surrounding constants — there's no clean unit-test surface for "submenu renders at expected width" without standing up the layout pipeline. Existing test_unified_new_session_menu_uses_new_worktree_config_label_and_order / test_unified_new_session_menu_includes_reopen_closed_session continue to cover the menu's structural invariants.

• I have manually tested my changes locally with ./script/run (via cargo build --bin warp-oss --features gui).

Screenshots / Videos

No user-visible visual change in the screenshots already attached to #10269 — that bug is upstream of this change. The behavior change here is for users with FeatureFlag::ShellSelector disabled (the OSS path), where the submenu now appears 300 px wide instead of 186 px, matching the experience users with ShellSelector enabled already get.

Agent Mode

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

CHANGELOG-IMPROVEMENT: New-session submenus render at a consistent 300 px width regardless of the ShellSelector feature flag state.

[oz-for-oss]

@lonexreb

This PR is not linked to an issue that is marked with ready-to-implement.

Issue-state enforcement details:

• Associated same-repo issues checked: none

• Required readiness label: ready-to-implement

To continue, link this PR to a same-repo issue such as Closes #123 in the PR description, and make sure that issue has ready-to-implement.

Powered by Oz

[oz-for-oss]

@lonexreb

This PR is not linked to an issue that is marked with ready-to-implement.

Issue-state enforcement details:

• Associated same-repo issues checked: none

• Required readiness label: ready-to-implement

To continue, link this PR to a same-repo issue such as Closes #123 in the PR description, and make sure that issue has ready-to-implement.

Powered by Oz

[lonexreb]

Closing this — I should have surveyed open PRs against #10269 before opening this. PR #10542 (already approved) is the real fix and lands the chevron menu width consistency at the right layer (MENU_DEFAULT_WIDTH vs 268 reconciliation across both menu variants, with a net code reduction).

The rename + comment-clarification in this PR was based on a misreading of which menu the user actually clicks from the tab bar; the architectural follow-up I referenced doesn't apply once #10542 lands. Apologies for the noise — thanks for the patience.