35. v0.16.3 — Watchlist lock recovery

Release candidate prepared 2026-09-20. This patch release finishes the repair shipped in v0.16.2: a locked watchlist now re-checks itself on every visit instead of giving up for good, so it unlocks as soon as whatever blocked it is gone.

Fixed

• A locked watchlist could still end up locked for good. v0.16.2 unlocks a watchlist by reading the backup copy written alongside it and confirming the two agree. Two things could stop that. The browser might have discarded the backup, leaving nothing to compare against. Or the check would compare your saved watchlist against a freshly generated starter list — one the app had just invented for the occasion, which your lists were never meant to match. Either way the app recorded a disagreement, and a disagreement was final: it was never looked at again, on that browser, ever. The lists were always intact; only writing was blocked.

  Two things changed. Where there is no backup and no older copy to bring forward, the saved watchlist is the only copy there is, so the app now checks it against itself rather than against a generated list — the only question that means anything in that situation. And a lock is no longer permanent: it records what the last attempt found, and the next visit tries again from scratch. If the problem is still there the watchlist stays locked and says so; if it is gone, the watchlist unlocks.

  A real disagreement is still caught. Where an older copy of your watchlist exists and genuinely differs from the saved one, the app locks the list on every visit rather than quietly picking a winner. Data written by a newer version of the app is still left strictly alone.

  Browsers stuck in any of these states unlock on the next visit, keeping the watchlist they had.

Verification

• The complete automated suite (388 files / 3,333 tests), TypeScript, the zero-warning ESLint baseline, and the optimized production build (129/129 static pages) passed on the release-preparation tree.
• Three new tests. Two reproduce stuck browsers — one whose backup was discarded, one that a later load had already written off as a disagreement — and both fail on v0.16.2. The third pins that a saved watchlist genuinely disagreeing with an older copy still locks, on every load, which is what makes the other two a fix rather than a loosening.
• Followed end to end in a real browser on optimized production builds of all three versions: a profile locked by v0.16.1, its backup then deleted, stays locked on v0.16.2 and unlocks on this release with its lists intact and edits that survive a reload.

Next steps

Back to the release list.

Next: Release Notes