max / makenotwork

multithreaded: make the live-post predicate a generated column, sweep the sites Closes the escalation trigger from the Run #3 re-verify cluster (problem fd1c52ca). A post is live iff removed_at AND deleted_at are both null, and that pair was hand-copied at every read. Five sites drifted: the search CTE, the tracked-thread unread count, the tracked-thread mention flag, the quote loader, and the thread-list mention badge. Two were wrong in production behaviour, not merely latent. The failure mode is specifically "wrote one predicate, forgot the other", so migration 034 makes that unrepresentable rather than adding another rule to remember: posts.is_active, GENERATED ALWAYS, one token at the call site. Postgres rejects any direct write to it, so it cannot drift from its two sources the way a copied predicate can. Both properties have tests. Of the three mechanisms considered, this was the one left standing. A shared Rust constant is impossible: sqlx's macros take a string literal, and query_scalar!(concat!(...)) fails to compile. A posts_active view only serves part of the surface, since four readers deliberately want removed rows (list_posts_in_thread renders tombstones, PostForEdit has to resolve a removed post for restore, the flag queue shows flags on hidden posts). Swept all ten read sites across six query modules. Deliberately not swept: the write guards in mutations, which key on removed_at specifically because they are the thing that sets it, and the mod-facing reads that want removed_at IS NOT NULL. idx_posts_active mirrors idx_posts_not_removed's shape and the planner picks it for an is_active predicate. The old index stays for now; after this sweep no query reads it, but the remaining removed_at IS NULL uses are PK-equality write guards, and settling whether it is droppable wants production index stats rather than a plan against an empty dev table. Noted in the migration.