🤖 refactor: centralize workspace ai settings persistence

[ammar-agent]

Summary

• Centralize workspace AI settings persistence behind a local-first backend adapter so UI callsites only touch localStorage.

Background

• The current approach requires per-callsite backend writes and manual stale-metadata guards. This follow-up makes backend persistence behave like localStorage by funneling writes through a shared adapter with a single pending-guard implementation.

Implementation

• Added a generic persisted-state backend adapter (createLocalFirstBackend) and optional backend wiring in usePersistedState/updatePersistedState.
• Implemented workspaceAiSettingsBackend to translate workspace AI settings updates into updateAgentAISettings calls and centralize stale-metadata filtering.
• Updated AI settings callsites to use updatePersistedState(..., { backend }) and WorkspaceContext to apply backend metadata via the adapter.
• Added a unit test covering local-first pending behavior.

Validation

• make static-check

Risks

• Low–medium: touches core persisted-state helpers and workspace AI settings sync; mitigated by local-first guard and test coverage of stale-remote handling.

---

Generated with mux • Model: openai:gpt-5.2-codex • Thinking: xhigh • Cost: $10.50

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2eaf9cda53

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Allow unrelated agent updates while a pending write exists

Because shouldApplyRemote only accepts a remote payload when the entire value equals the pending value, any pending write blocks all remote updates for that key until the full object matches. With workspace AI settings, the pending value is the whole per-agent map, so if another device updates a different agent while a local write is pending, the backend metadata will include extra changes and never equal the pending map. That means applyWorkspaceAiSettingsFromBackend will keep rejecting metadata and the remote agent update can be ignored indefinitely. Consider tracking pending at the agent level or comparing only the subset that was written so unrelated agent updates can still apply.

Useful? React with 👍 / 👎.