fix(multi-user): read a refused settings write as admin-only in the browser

Two gaps in how a regular user's browser handled the admin-only settings
writes:

- The role comes from GET /api/me, which answers after page load, and on
  a failed request admin-ui.js falls back to a single-user admin. A save
  made then was sent, came back 403, and still said "Settings saved",
  while the refused server-wide change stayed on the device. A 403
  FORBIDDEN on a settings write now ends that save like a known
  non-admin's: synced keys back to the server's value, the one admin-only
  notice, and the page is read-only from then on (_noteSettingsWriteRefusal).
  The display-key list moved into one method (_displaySettingKeySet), so
  that split no longer depends on GET /api/settings having loaded.
- A regular user's run mode and respawn presets were skipped for the
  server but overwritten by the server's on the next page load, while
  "Saved preset" said otherwise. They are now kept as that user's own on
  the device and put back over the server's after the settings load and
  on codeman:me (_rememberOwnSetting, _applyOwnSettings).

Admins and single-user mode are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

test/tab-cli-logos-setting.test.ts

@@ -82,6 +82,8 @@ const REAL = new Set([
   // Real so the save builds the body a browser would send (the schema check).
   'resolveHeaderStatsStyle',
   'resolveSessionSidebarFontSize',
+  // The display-key list the load merge reads (settings-ui.js keeps it in one method).
+  '_displaySettingKeySet',
 ]);
 
 /**