fix(statusline): GET /api/settings never writes, and a save sends the collection switch only on a flip

Two follow-ups to #361's sticky telemetry switch.

GET /api/settings reconciled an absent showPlanUsageLimits by persisting
true, but readJsonConfig() answers {} for ANY read failure (a parse
error, EACCES, EMFILE, a read landing inside PUT's non-atomic write), not
only ENOENT, and every page load calls this route, so one unlucky read
replaced the whole settings file with a one-key file. The route is a
plain read again and the default moved into the reader:
readPlanUsageTelemetryEnabled() treats an absent key as ON, the same way
readWorkspaceHooksEnabled() does, which is what the desktop chip already
shows for an install that never touched the setting.

saveAppSettings() sent showPlanUsageLimits on every save. The chip
defaults OFF on handhelds, so a phone saving its font size persisted
false and switched collection off for every desktop, whose chip then
went stale with no error anywhere. The key is now stripped like the
other per-device display keys and re-added only when the save FLIPS the
chip relative to what the device had (planUsageCollectionFlip), so an
explicit toggle on any device still writes it in either direction.

Tests pin both: the GET route with a mocked filesystem (absent, missing,
EACCES, garbage, explicit), the reader default, and the flip helper plus
its wiring in saveAppSettings.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

src/hooks-config.ts

@@ -1044,10 +1044,21 @@ export async function ensureStatusLineExporterScript(): Promise<string> {
  * to thread a request-time flag through: they all already construct a
  * session via TmuxManager.createSession/respawnPane, which reads this at
  * spawn time.
+ *
+ * An ABSENT key means ON, mirroring readWorkspaceHooksEnabled() above: the
+ * client shows the chip and its checkbox as already on for a desktop that has
+ * never touched the setting (planUsageChipEnabled() in settings-ui.js), and
+ * the exporter only ever posts to THIS Codeman over loopback, so the honest
+ * default for an install that never said otherwise is the one the user can
+ * see. Resolving the default here, in the reader, is what lets
+ * `GET /api/settings` stay a plain read: a reconcile write there ran on every
+ * page load and could replace an unreadable settings.json with a one-key
+ * file. Only an explicit `false` (a save that flipped the chip off on some
+ * device) turns collection off.
  */
 export async function readPlanUsageTelemetryEnabled(): Promise<boolean> {
   const settings = await readJsonConfig<Record<string, unknown>>(SETTINGS_PATH, 'settings.json', {});
-  return settings.showPlanUsageLimits === true;
+  return settings.showPlanUsageLimits !== false;
 }
 
 /**

src/web/public/settings-ui.js

@@ -2315,21 +2315,25 @@ Object.assign(CodemanApp.prototype, {
     // and syncing would leak mobile's hidden-checkbox false onto desktop); it's
     // also absent from SettingsUpdateSchema, which is .strict() — sending it
     // would 400 the whole settings PUT.
-    // showPlanUsageLimits is the ONE exception to "per-device keys never sync":
-    // its DISPLAY stays per-device (loadAppSettingsFromServer only seeds it into
-    // localStorage when a device has no value yet — same as every other display
-    // key), but it ALSO doubles as the server-side plan-usage telemetry
+    // showPlanUsageLimits is per-device for DISPLAY (loadAppSettingsFromServer
+    // only seeds it into localStorage when a device has no value yet, like every
+    // other display key) but ALSO doubles as the server-side plan-usage telemetry
     // COLLECTION switch (readPlanUsageTelemetryEnabled in hooks-config.ts, read
-    // fresh at every claude session create/respawn), so unlike the others it
-    // MUST flow through in `serverSettings` below on every save — including
-    // OFF, which used to be un-sendable under the old one-way "ENABLE only"
-    // action field this replaces.
+    // fresh at every claude session create/respawn). So it is stripped here like
+    // the others and re-added below ONLY when this save FLIPS it on this device
+    // (planUsageCollectionFlip): the chip defaults OFF on handhelds, so sending
+    // it on every save let a phone saving its font size persist `false` and
+    // switch collection off for every desktop, whose chip then went stale with
+    // no error anywhere. An explicit toggle on any device still writes it, in
+    // either direction.
+    const _chipFlip = this.planUsageCollectionFlip(_prev, settings.showPlanUsageLimits);
     const {
       localEchoEnabled: _leo,
       cjkInputEnabled: _cjk,
       extendedKeyboardBar: _ekb,
       skin: _skin,
       language: _language,
+      showPlanUsageLimits: _pul,
       showAttachmentsButton: _ahb,
       showFileViewerButton: _fvb,
       webglRendererEnabled: _wgl,
@@ -2364,6 +2368,7 @@ Object.assign(CodemanApp.prototype, {
     try {
       const res = await this._apiPut('/api/settings', {
         ...serverSettings,
+        ...(_chipFlip !== undefined ? { showPlanUsageLimits: _chipFlip } : {}),
         notificationPreferences: notifPrefsToSave,
         voiceSettings,
       });
@@ -2637,6 +2642,18 @@ Object.assign(CodemanApp.prototype, {
     return s.showPlanUsageLimits ?? this.getDefaultSettings().showPlanUsageLimits ?? true;
   },
 
+  // What a settings save tells the server about plan-usage COLLECTION: the new
+  // chip value when this save FLIPS it relative to what this device resolved
+  // before (stored value, else the per-device default), otherwise undefined,
+  // meaning "say nothing". The server reads an absent key as ON, so a device
+  // that never touched the chip leaves collection alone, and a handheld (chip
+  // default OFF) cannot switch it off for every desktop by saving its font
+  // size. Pure so test/plan-usage-collection-flip.test.ts can drive it.
+  planUsageCollectionFlip(prevSettings, now) {
+    const before = this.planUsageChipEnabled(prevSettings ?? {});
+    return now === before ? undefined : now;
+  },
+
   applyHeaderVisibilitySettings() {
     const settings = this.loadAppSettingsFromStorage();
     const defaults = this.getDefaultSettings();

src/web/routes/system-routes.ts

@@ -936,47 +936,18 @@ export function registerSystemRoutes(
   // ========== Settings ==========
 
   app.get('/api/settings', async () => {
-    const settings = await readJsonConfig<Record<string, unknown>>(SETTINGS_PATH, 'settings', {});
-
-    // Plan-usage chip default reconciliation (PR #361 follow-up): the client's
-    // own default resolution (planUsageChipEnabled() in settings-ui.js) shows
-    // the header chip and the App Settings checkbox as already ON whenever this
-    // key has never been set — a discoverability default from 1.9.3, unrelated
-    // to consent. Meanwhile readPlanUsageTelemetryEnabled() (hooks-config.ts)
-    // deliberately treats an absent key as "no telemetry" (privacy: never POST
-    // usage data without an explicit persisted yes, pinned by its own unit
-    // tests). Nothing ever reconciled those two independent guesses, so a
-    // fresh install showed a checked box that silently did nothing until the
-    // user opened Settings and hit Save at least once — verified live: an
-    // install that had never touched this setting had NO showPlanUsageLimits
-    // key in settings.json, and its running Claude process's argv carried no
-    // --settings flag at all, i.e. zero telemetry ever collected.
-    //
-    // Resolve it ONCE, here, the first time anything reads settings: if the
-    // key is truly ABSENT (never explicit true or false), persist the same
-    // desktop-default-ON resolution the client already shows, so "chip visible"
-    // and "telemetry collected" become the same fact instead of two defaults
-    // that happen to disagree. readPlanUsageTelemetryEnabled()'s own
-    // absent-means-false contract is untouched — after this runs once the key
-    // is never absent again, so that branch stays correct in isolation (its
-    // unit tests keep passing unmodified) while being unreachable in practice
-    // for any install that has ever called this route. An explicit false the
-    // user sets afterward is respected forever; this only fires on true absence.
-    if (!('showPlanUsageLimits' in settings)) {
-      settings.showPlanUsageLimits = true;
-      try {
-        const dir = dirname(SETTINGS_PATH);
-        if (!existsSync(dir)) {
-          mkdirSync(dir, { recursive: true });
-        }
-        await fs.writeFile(SETTINGS_PATH, JSON.stringify(settings, null, 2));
-      } catch {
-        // Best-effort: the resolved default still reaches this response even
-        // if the write fails, so the caller sees consistent data either way.
-      }
-    }
-
-    return settings;
+    // A plain read. This route must NEVER write settings.json: readJsonConfig()
+    // answers `{}` for ANY read failure (a parse error, EACCES, EMFILE, a read
+    // that lands inside PUT's non-atomic write), not only for a missing file,
+    // and every page load calls this route, so a "persist the default when the
+    // key is absent" reconcile here replaced a whole settings file with one key
+    // on the first unlucky read. The plan-usage default is resolved by the
+    // READERS instead: an absent `showPlanUsageLimits` means ON to
+    // readPlanUsageTelemetryEnabled() (hooks-config.ts), the same way an absent
+    // `workspaceHooksEnabled` means ON, and the client resolves its own display
+    // default through planUsageChipEnabled(). Pinned by
+    // test/routes/system-routes-settings-get-plan-usage-default.test.ts.
+    return readJsonConfig(SETTINGS_PATH, 'settings', {});
   });
 
   app.put('/api/settings', async (req) => {

src/web/schemas.ts

@@ -1299,7 +1299,9 @@ export const SettingsUpdateSchema = z
     // Doubles as the plan-usage telemetry COLLECTION switch, read fresh from
     // disk by readPlanUsageTelemetryEnabled() (hooks-config.ts) at every claude
     // session create/respawn — not just the chip's DISPLAY preference. See that
-    // function's doc comment for why one persisted field serves both.
+    // function's doc comment for why one persisted field serves both. Absent
+    // means ON there, and the client sends it only on a save that flips the
+    // chip (planUsageCollectionFlip in settings-ui.js), never on every save.
     showPlanUsageLimits: z.boolean().optional(),
     showRedrawButton: z.boolean().optional(),
     // Input