feat(supersession): the relation, and the dead column that stood where it should

Step 1 of #278. Structure only — nothing reads or writes the new table yet.

Old records outrank newer ones on the same subject because a similarity score
cannot tell time. A note that accurately described how something worked in June
is still accurate ABOUT June; it is just no longer the answer. Nothing recorded
that, so nothing could act on it.

`note_supersessions(superseder_id, superseded_id)`. The claim points FORWARD —
the newer record names what it overtakes — because the older one cannot know it
has been overtaken; asking it to record its own obsolescence is asking it to
predict the future.

A table rather than a column because the relation is genuinely many-to-many and
partial, and both directions are hot: superseded_id answers "has this been
overtaken?" at ranking time, superseder_id answers "what does this replace?" in
a record view. An array column serves one and not the other.

CASCADE is safe because trashing is not a delete — trash_svc stamps deleted_at,
so a trashed note keeps its claims and restore brings them back. It fires only
on purge_trash, where a claim about the row would be unactionable anyway. A
CHECK rejects self-supersession, which under flat demotion would let a record
demote itself.

## consolidated_at, and what it actually was

Dropped. Written by nothing while serialised into every note and task payload
as null — and worse, it implied a capability.

The survey (#2483) read it as note consolidation modelled and abandoned. That
was wrong, and the frontend is what says so: `TaskViewerView` rendered
"✦ Auto-summarized from work logs" gated on this column. It is a survivor of
the pre-pivot auto-summary subsystem (migration 0030), whose own column #599
removed. Not an unbuilt feature — an outlived one.

So four more remnants went with it: the banner, its CSS, a `consolidatedAt` ref
in TaskEditorView assigned and never read, and `.auto-summary-banner-editor`
styling with zero template usage. That last one is presence-without-reference
in the same family as the column itself.

Dropped rather than repurposed for supersession, and the distinction is the
point: consolidation folds records into one survivor and destroys the
originals. Supersession is the opposite — both survive, the older ranks behind.
Smuggling one in under a column named for the other would bury that in schema.

## The hard delete_note

Removed, with a comment where it stood. Zero callers, and the danger was never
that it ran — it is that it was findable by name. Someone wanting to delete a
note greps `delete_note`, finds a function in the notes service with exactly
the right signature, and permanently destroys a record every path downstream
expects to be recoverable. The MCP tool of the same name already went through
trash_svc; only the service function was the trap.

Refs #278, #2483

alembic/versions/0076_note_supersessions.py

@@ -0,0 +1,115 @@
+"""note_supersessions; drop the never-written notes.consolidated_at
+
+Revision ID: 0076
+Revises: 0075
+Create Date: 2026-08-07
+
+Step 1 of milestone #278. Structure only — nothing reads or writes the new
+table yet, and nothing behaves differently after this runs.
+
+## What the table is for
+
+Old records outrank newer ones on the same subject, because a similarity score
+cannot tell time. A note that accurately described how something worked in June
+is still accurate ABOUT June; it is just no longer the answer. Nothing recorded
+that, so nothing could act on it.
+
+The claim points FORWARD — the newer record names what it overtakes — because
+the older one cannot know it has been overtaken. Many-to-many and partial: a
+note may supersede parts of several others and be overtaken piecemeal by
+several later ones, which is why this is a table rather than a column. Both
+directions are queried: `superseded_id` answers "has this been overtaken?" at
+ranking time, `superseder_id` answers "what does this replace?" in a record
+view. An array column could serve one and not the other.
+
+CASCADE on both sides is safe because trashing is not a delete: `trash_svc`
+stamps `deleted_at`, so a trashed note keeps its claims and `restore` brings
+them back. The cascade fires only on `purge_trash`, where the row genuinely
+goes — and a claim about a row that no longer exists is not actionable.
+
+## What is being dropped, and why now
+
+`notes.consolidated_at` was written by NOTHING — no service, no route, no tool
+— while being serialised into every note and task payload as `null`. It cost a
+column, a line in every response, and worse: it IMPLIED a capability. A reader
+reasonably concludes notes can be consolidated and this records when.
+
+That reading was reasonable precisely because merge/unmerge exists for snippets
+and not for notes, so the column looked like the notes-side half of that
+feature, modelled and abandoned.
+
+It is dropped rather than repurposed for supersession, and the distinction is
+the point (#2483): consolidation folds several records into one survivor and
+destroys the originals. Merging two snippets is lossless — one helper, several
+call sites. Folding two dev-logs means writing a summary and losing what each
+actually said. Supersession is the opposite act: both records survive, and the
+older one is merely ranked behind. Smuggling one in under a column named for
+the other would have buried that difference in schema.
+
+## Downgrade
+
+Re-adds `consolidated_at` nullable, which is how it lived — so downgrade
+restores the shape, not the (nonexistent) data. Drops the table; any recorded
+supersession claims are lost, which costs ranking its input and nothing else,
+since no note's own content depends on them.
+"""
+import sqlalchemy as sa
+from alembic import op
+
+revision = "0076"
+down_revision = "0075"
+branch_labels = None
+depends_on = None
+
+
+def upgrade() -> None:
+    op.create_table(
+        "note_supersessions",
+        sa.Column("id", sa.Integer, primary_key=True),
+        sa.Column(
+            "superseder_id",
+            sa.Integer,
+            sa.ForeignKey("notes.id", ondelete="CASCADE"),
+            nullable=False,
+        ),
+        sa.Column(
+            "superseded_id",
+            sa.Integer,
+            sa.ForeignKey("notes.id", ondelete="CASCADE"),
+            nullable=False,
+        ),
+        sa.Column(
+            "created_at",
+            sa.DateTime(timezone=True),
+            server_default=sa.text("now()"),
+            nullable=False,
+        ),
+        sa.UniqueConstraint(
+            "superseder_id", "superseded_id", name="uq_note_supersessions_pair"
+        ),
+        # Declaring that a note supersedes ITSELF is meaningless, and under flat
+        # demotion it would demote a record on its own authority. Refused in the
+        # service too, with a message — this is the backstop that holds when
+        # something writes rows directly.
+        sa.CheckConstraint(
+            "superseder_id <> superseded_id", name="ck_note_supersessions_not_self"
+        ),
+    )
+    op.create_index(
+        "ix_note_supersessions_superseder", "note_supersessions", ["superseder_id"]
+    )
+    op.create_index(
+        "ix_note_supersessions_superseded", "note_supersessions", ["superseded_id"]
+    )
+
+    op.drop_column("notes", "consolidated_at")
+
+
+def downgrade() -> None:
+    op.add_column(
+        "notes",
+        sa.Column("consolidated_at", sa.DateTime(timezone=True), nullable=True),
+    )
+    op.drop_index("ix_note_supersessions_superseded", table_name="note_supersessions")
+    op.drop_index("ix_note_supersessions_superseder", table_name="note_supersessions")
+    op.drop_table("note_supersessions")