fix(desktop): share settings sidebar width

[lucas77778]

Fix

Share the persisted sidebar width between Settings and the workbench to prevent misalignment when switching views.

Validation

• pnpm check:ci passed; pnpm test: 3040 passed, 1 skipped.
• Verified default width, resizing, navigation, and reset in Electron. Acceptance recording.

Fixes CODE-653

[linear-code]

CODE-653

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[pullfrog]

✅ No new issues found.

Reviewed changes — one file, one commit: the Settings overlay now derives its --lc-sidebar-w from the shell store instead of a hard-coded default.

• Width source moved to the store — SETTINGS_CHROME_STYLE (module-scope, DEFAULT_LAYOUT.sidebarW = 288) is replaced by a per-render settingsChromeStyle reading useDesktopShellStore((state) => state.layout.sidebarW), so the Settings nav column matches the width the user dragged the workbench sidebar to. --lc-right-w / --lc-bottom-h stay 0px and the DEFAULT_LAYOUT import is dropped.

What I checked and found sound: layout.sidebarW is the durable truth (sash drags write the CSS variable imperatively per frame and only commit to the store in onResizeEnd, and Settings is never open mid-drag); zodPersist hydrates synchronously from localStorage, so there is no pre-hydration flash of the old default; the value is always clamped to [240, 520] by normalizeLayout; and Settings' own chrome divider still lands on the nav edge, because its --lc-sidebar-col cap (100cqw - 360, with --lc-right-w at 0px) is at least 580 at the 940px minimum window size and so never bites against the 520px maximum sidebar. Not consulting sidebarOpen is right here — the Settings nav column holds Back and search, so it has to stay visible.

ℹ️ Sharing the stored width still leaves a jump when the workbench itself is clamping

The workbench sidebar track is --lc-sidebar-col, which subtracts --lc-right-min (320px while the right panel is open); Settings sets --lc-right-w: 0px, so its cap is much looser. At a 1100px content width with the right panel open and sidebarW at 500, the workbench paints 420px and Settings paints 500px — an 80px shift of exactly the kind this PR removes for the common case. Flagging it as a known remainder, not as something to fix here.

Technical details

# Effective vs. stored sidebar width across the Settings overlay

## Affected sites
- `apps/desktop/src/renderer/src/settings/settings-view.tsx:80` — feeds the raw stored `sidebarW` into `--lc-sidebar-w`.
- `apps/desktop/src/renderer/src/settings/settings-view.tsx:258` — the nav column is `w-(--lc-sidebar-w)`, unclamped.
- `apps/desktop/src/renderer/src/index.css:78-82` — `--lc-sidebar-col` clamps against `100cqw - --lc-main-min - --lc-right-min`, so the workbench's painted width can be narrower than the stored one.

## Required outcome
- None required. Recording the residual case so it is not mistaken for a regression later.

## Open questions for the human
- Is matching the workbench's *painted* width (not just the stored one) in scope for CODE-653? Doing it exactly would mean Settings has to account for the workbench's right-panel width while rendering no right panel of its own, which looks like more complexity than the remaining mismatch is worth.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}