Replaces OD-3139

Summary

OneDev exposes a toggle half screen control on several views - issues, pull requests, and any other screen that offers it. Today that state is not remembered: a user who turns it on must turn it on again every time they open an issue, a pull request, or any other view that has the control.

Problem

The user's intent is being discarded, which creates repetitive friction. If the toggle was left on, opening a new issue/PR should already show half screen; if it was left off, it should open off. Re-selecting it on every view implies the UI is not paying attention to an obvious, stable preference.

Desired behavior

• Remember the user's last choice of the toggle half screen control.
• If it was last on, every relevant view opens with it already on.
• If it was last off, every relevant view opens with it already off.
• Remember it silently - no extra "save preferences" step or dialog.
• Persist it in local browser storage, per device (not per user, not in the database). It is acceptable if a new device or a new browser session starts from the default; the goal is to stop re-toggling on every single page.

Scope

• Applies to every view that currently exposes the toggle half screen control (issues, pull requests, and any other such screen).
• Does not require any server-side, account-level, or database changes.
• Does not affect anonymous users - persistence is purely client-side, so it works the same regardless of sign-in state.

Implementation approach: follow the light/dark mode persistence pattern

Rather than inventing a new mechanism, this should reuse the same client-side pattern already used for remembering the user's light/dark mode choice. The concrete details below must be confirmed by reading the source before implementing, since they are not verified here:

• Identify how the light/dark mode preference is stored (expected: browser local storage, e.g. a key such as theme or similar) and where the read/write helpers live.
• Identify how the preference is read on page/view load so the correct mode is applied before render, and how it is written when the user changes it.
• Mirror that exact pattern for the toggle half screen state: a dedicated storage key, read on view initialization to pre-apply the toggle, and written on every user change (on and off).
• Reuse the existing storage abstraction/helpers and naming conventions so the two preferences behave consistently and stay easy to find.
• Ensure multi-tab behavior is at least as good as the existing theme behavior (i.e. no regression relative to how theme currently handles other open tabs).

Notes to confirm during investigation

• Exact storage key/name used for theme, and whether it is namespaced.
• Whether the theme value is read per-render, per-app-init, or both.
• Whether any shared utility (a "client preferences" helper) already exists that both preferences should use.
• Default value for toggle half screen when no stored value exists (assumed: current default / off unless the current default is otherwise).