sessions: Refine Show/Hide Editor placement, icons, and Browser-tab fallback

Follow-up to #329384 (merged), addressing feedback on that PR's
Show/Hide Editor Area actions:

- Moves Hide Editor / Show Editor from the full-width editor header's
  trailing layout group to the tab strip's editor-title layout cluster
  (`MenuId.EditorTitleLayout`), immediately after Maximize/Restore
  Editor Area (order 20 vs. 10). Toggle Details remains alone in the
  header's trailing group.
- Both actions now always render regardless of whether the active tab
  has a docked detail panel (drops the `HasDockedDetailsContext` gate),
  matching Maximize/Restore's own always-shown behavior in that
  cluster.
- Switches their icons to the existing `right-panel-hide` /
  `right-panel-show` codicons (previously `chevron-right` /
  `chevron-left`, which are already heavily reused elsewhere in this
  window for tree/list disclosure twisties).
- Hide Editor is always enabled (drops its `AuxiliaryBarVisibleContext`
  precondition) and unconditionally reveals the auxiliary bar in
  `run()`.
- Fixes a resulting regression: clicking Hide Editor while a Browser
  tab was active would immediately re-hide the just-revealed detail
  panel, since `SinglePaneDetailPanelStrategy`'s "Browser hides the
  detail" rule fired again right away. The strategy now only
  transiently hides the detail for a Browser tab while the editor area
  itself stays visible; once the editor area is hidden (e.g. via Hide
  Editor), the panel shows the same Changes/Files fallback a session
  with no active editor gets, since it would otherwise be the only
  thing left on screen. Revealing the editor area again (Show Editor)
  restores the normal transient-hide behavior.

Updates SINGLE_PANE_SCENARIOS.md and LAYOUT.md to document the new
placement, icons, always-enabled state, and Browser-tab fallback, and
adds/updates targeted tests covering the menu placement, the action's
unconditional reveal, and the strategy's Browser-tab fallback end to
end.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: sandy081

src/vs/sessions/LAYOUT.md

@@ -293,7 +293,7 @@ The entire third-pane redesign is gated behind the experimental setting `session
 - Revealing the side pane from *closed* (`setEditorHidden(false)`, e.g. the session-header Changes button opening the Changes editor) passes `Sizing.Distribute` to `SerializableGrid.setViewVisible`. The grid already knows the revealed view's location, so it distributes that containing split and Sessions and the side pane receive equal space without either part computing pixels, percentages, or a split reference. The side pane sash's double-click reset uses the same native grid distribution because the visible editor part has no fixed `preferredWidth`. In docked mode this runs on every reveal that has no saved user width to restore; a genuinely user-chosen width still takes precedence.
 - Side-pane sizes are **workbench-level, not per session**: the editor grid node width is owned by the workbench grid and persisted globally (`workbench.sessions.partSizes`), so switching between sessions keeps the same side-pane width the user last set — the layout controller does not track or restore a per-session width. The workbench persists the docked side-pane geometry across reloads via `_savePartSizes` on `onWillSaveState`, restored by `createDesktopGridDescriptor`. Because the docked detail (auxiliary bar) lives **inside** the editor grid node, the persisted editor value is the pure editor-content width: `_persistedEditorWidth` subtracts the docked detail width **only when the detail is visible**, mirroring the descriptor, which adds it back only when the detail is visible. Subtracting it unconditionally (the earlier bug) shrank an **Editor-only** session's side pane by the detail width on every reload, compounding toward zero.
 - `_dockedEditorSizeBeforeHide` is captured on hide **only for "Hide Editor"** (detail/auxiliary bar still visible, so the editor node stays visible at a real user-chosen width). When the **whole** side pane closes, the editor grid node collapses to `0px`; that is not captured as a user width, so reopening falls through to the last persisted width or the equal Sessions/side-pane split.
-- **Hide Editor** / **Show Editor** render in the tab strip's editor-title layout cluster (`MenuId.EditorTitleLayout`), immediately after **Maximize/Restore Editor Area** (order `20` vs. `10`). They are mutually exclusive, gated on `MainEditorAreaVisibleContext` being true/false respectively, so only one is present at a time — unlike the earlier design, they always show regardless of whether the active tab has a docked detail (no `HasDockedDetailsContext` gate), consistent with Maximize/Restore's own always-shown behavior in that cluster. Hide Editor remains in place but is disabled (via `precondition`) while the auxiliary bar is hidden; Show Editor needs no such precondition since the docked detail panel (or, for tabs with none, an empty docked panel) is necessarily visible whenever the tab strip renders with the editor area hidden (the editor node itself hides once both the editor content and the details are hidden). Hide reveals the auxiliary bar, hides the editor part, and restores the sessions list (freeing the space it may have auto-collapsed for). Show reveals the editor area via the same explicit-reveal path (`revealEditorPartExplicitly()`) as the session-header Changes pill, then focuses the editor group. The full-width editor header's own trailing layout-action host (separate from the tab-strip cluster; see above for its separator behavior) now holds **Toggle Details** alone; Toggle Details is hidden for Browser/Search tabs, which have no detail. Opening a file or diff from the detail panel reveals the editor again. If the detail-panel toggle hides the detail while editor content is hidden, it reveals the editor content instead of leaving the pane empty; **Toggle Side Panel** remains the separate action that can hide both.
+- **Hide Editor** / **Show Editor** render in the tab strip's editor-title layout cluster (`MenuId.EditorTitleLayout`), immediately after **Maximize/Restore Editor Area** (order `20` vs. `10`). They are mutually exclusive, gated on `MainEditorAreaVisibleContext` being true/false respectively, so only one is present at a time — unlike the earlier design, they always show and are always enabled regardless of whether the active tab has a docked detail or the detail panel is currently visible (no `HasDockedDetailsContext` gate, no `AuxiliaryBarVisibleContext` precondition), consistent with Maximize/Restore's own always-shown behavior in that cluster. Hide unconditionally reveals the auxiliary bar as part of its `run()` (so it always has somewhere to fall back to even if details were hidden beforehand), hides the editor part, and restores the sessions list (freeing the space it may have auto-collapsed for). Show reveals the editor area via the same explicit-reveal path (`revealEditorPartExplicitly()`) as the session-header Changes pill, then focuses the editor group. The full-width editor header's own trailing layout-action host (separate from the tab-strip cluster; see above for its separator behavior) now holds **Toggle Details** alone; Toggle Details is hidden for Browser/Search tabs, which have no detail. Opening a file or diff from the detail panel reveals the editor again. If the detail-panel toggle hides the detail while editor content is hidden, it reveals the editor content instead of leaving the pane empty; **Toggle Side Panel** remains the separate action that can hide both.
 - Changes opens as a **custom `SessionChangesEditor`** (the multi-diff editor; in single-pane its *Branch Changes* dropdown + diff-stats + primary actions render in the full-width header part above, so the editor itself is header-less and the diff fills the pane). Each file header shows the live `+insertions -deletions` counts from the selected changeset alongside the file label. Clicking a Branch Changes file honors the same `sessions.changes.openSingleFileDiff` setting and Alt inversion as the standard layout, opening either a docked single-file diff or revealing the file in this multi-diff editor. The auxiliary bar's composite tab strip + title are hidden, and `SinglePaneDetailPanelStrategy` maps the active editor tab to the detail container (Changes → files + Checks, File → Explorer, Browser → hidden). Activating a Changes/file editor switches the detail container to match but does **not** force-reveal a hidden detail — except when the empty Files placeholder becomes active or when the detail was transiently hidden by a Browser tab.
 - **Run Code Review** renders as the first inline action on the right while the single-pane Changes editor area is visible. When the editor area is collapsed, it moves into the first group of the right-side `...` overflow, followed by a separator and the remaining overflow actions.
 - Closing the last editor tab hides both the editor content and the docked detail panel, leaving the Agents window chat-only. Opening any tab reveals the editor part again, and `DetailPanelController` restores the matching detail content for File/Changes tabs.