bug: Preferences read failure can clear an existing tracing project

Problem

A transient Store read failure on the Settings page can cause a subsequent change to Default thread visibility to clear an existing Local tracing project, even though the user did not edit that field.

The preferences GET endpoint reports success with fallback values when the Store read fails. The page then includes those fallback values in its next save, overwriting the previously stored settings.

Reproduction

Reproduced at commit 0947af27e2ad564500ccb93bdc16b572cf557a08 using the repository's local E2E harness and the real dashboard in Chrome. GitHub/Slack and the model were simulated; the preferences page, API handlers, and Store persistence were real. The relevant backend and frontend files are also unchanged at 5ada173169361dd5852136e043a64f2871be052a.

1. Sign in as Alice and open /my-settings.
2. Set Local tracing project to alice-project and blur the input to save it. Leave Default thread visibility as Private.
3. In the local backend, inject one ConnectionError into the next agent.dashboard.user_preferences.get_value call for namespace ['user_preferences'], key alice. Let all subsequent reads use the real Store again.
4. Reload Settings so its preferences GET encounters that failure.
5. Change Default thread visibility to Workspace without editing the tracing project.
6. Reload Settings or read /dashboard/api/me/preferences again. The saved tracing project is now null.

The fault was injected at the backend Store-read boundary; the browser's API response was not stubbed. This reproduces a transient backend read failure, rather than a browser network error or a production incident.

Captured results

Stage	default_visibility	local_tracing_project
Initial saved preferences	private	"alice-project"
GET response after the injected failure, HTTP 200	private	null
Independent successful read before changing visibility	private	"alice-project"
Browser PUT after selecting Workspace, HTTP 200	public	null
Fresh GET after saving and reloading	public	null

The independent read confirms the original value remained stored until the UI submitted the save. As a control, changing visibility without injecting the read failure preserved alice-project.

Expected behavior

An unsuccessful settings read should be reported as an error, with retry available and dependent edits disabled. It should not present fallback values as successfully loaded saved settings or silently overwrite another preference.

A genuinely absent preferences record should still receive the usual defaults.

Cause and proposed fix

• get_user_preferences catches Store exceptions and normalizes them to defaults. The settings GET route uses that same fallback path.
• The visibility selector submits the loaded preferences together with the changed visibility. The save function then persists the fallback null over the existing project.

I propose keeping this fix focused:

• Use a strict Store read for the settings GET endpoint and return an error, such as HTTP 503, when the read fails.
• Show the load error and a retry action, and prevent saving the server-backed preferences until a successful read.
• Preserve the existing fallback behavior for agent/thread creation, where a preferences outage should not prevent a run.
• Add focused backend and UI regression tests for read failure, retry, preservation of the other setting, and missing-record defaults.

I would like to implement this fix. Would a maintainer confirm whether this approach is acceptable before I submit a PR?