v1.9.5 — drop the settings table

settings is dropped. The three-release move that started in 1.7.0 is finished.

Changed

• Migration 0013 drops the legacy settings table (#234, release three of three). 0010 created user_settings and wrote both; 1.9.0 stopped writing the old one and carried no migration at all, which is the release that makes this one safe and the one that looked skippable. Nothing in store.ts has read or written settings since.

  🔴 The ordering is the whole point (ADR-002 §3): make migrate runs before make deploy, so the Worker live while the drop executes is the previous release. That Worker has to already be a non-writer, and both environments are. Skip the middle release and the drop lands under a live writer, and nothing fails loudly — the writes just start erroring against the only copy of the setting.

• The guard in users-scoping.test.ts changed shape rather than going away. It used to select from settings and assert no row came back; it now asserts the table is absent from sqlite_master, which is the stronger question — a mirror write that came back would fail against a missing table instead of quietly repopulating one.

• Three stale comments and one spec line fixed: deleteUserHard's doc listed "settings" where it deletes user_settings, writeSetting's header described itself as release two, and spec §14 still named settings as where the operator's agent text lives.

Note for the prod deploy

This is the first destructive migration knag has shipped. Both workflows back up D1 as their first step, so the backup happens before the migration runs. Verified on dev after deploy: settings is gone, user_settings and every other table intact.

Full changelog: v1.9.4...v1.9.5