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

src/scribe/services/notes.py

@@ -373,17 +373,16 @@ async def update_note(user_id: int, note_id: int, **fields: object) -> Note | No
     return note
 
 
-async def delete_note(user_id: int, note_id: int) -> bool:
-    async with async_session() as session:
-        result = await session.execute(
-            select(Note).where(Note.id == note_id, Note.user_id == user_id)
-        )
-        note = result.scalars().first()
-        if note is None:
-            return False
-        await session.delete(note)
-        await session.commit()
-        return True
+# A hard `delete_note(user_id, note_id)` lived here with ZERO callers, and was
+# removed with #278 step 1. It is recorded rather than silently dropped because
+# 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 delete path is `trash_svc.delete`, which soft-deletes an entity AND its
+# descendants under one batch_id so `restore(batch)` works. `purge_trash` owns
+# permanent deletion. Both are reachable; neither is spelled `delete_note`.
 
 
 async def get_all_tags(user_id: int, q: str | None = None) -> list[str]: