fix(notes): søgningen svarede med det forkerte først, og et træk gjorde ingenting

**Søgningen sorterede efter dato.** Usynligt med ti noter og ubrugeligt med tolv
hundrede: de blev alle importeret samme aften, så `updated_at` siger ingenting, og
loftet skar listen af ved halvtreds vilkårlige rækker. At søge "Tesla" svarede med
en note om nginx først og noten, der hedder "Tesla Model Y", bagefter — hvilket
læses som en søgning, der ikke virker, fordi det fra brugerens plads er præcis
dét.

Nu bm25, med titlen vægtet ti gange kroppen: et ord i titlen er, hvad noten
*handler om*, mens det samme ord én gang i en lang krop er en henvisning. `fold`
vejer som kroppen, ellers ville et dansk match slå et præcist. Sammenføjet frem
for `rowid IN (…)`, fordi rangeringen hører til matchet, og en underforespørgsel
smider den væk. Fladen sorterer ikke om, når der er søgt — det ville kaste netop
det væk, der gør en søgning i tolv hundrede noter brugbar.

**Et træk af en note hen på et projekt gjorde ingenting.** `ondragover` tog imod
både opgaver og noter, så rækken lyste op — og `ondrop` sendte kun opgaver videre,
mens noten faldt ned i grenen, der omarrangerer projekter, hvor den ikke betyder
noget. Den værst mulige form for i stykker: den så ud, som om den ville virke,
helt indtil man slap.

Det står i overleveringen som "virker i koden, men ikke fastholdt i prøver, fordi
prøven blev upålidelig". Den er skrevet igen, og den ser på resultatet — ligger
noten i projektet bagefter — frem for på om rækken blev fremhævet, hvilket var
netop det, den gamle kunne se og som blev ved med at være sandt, mens funktionen
var i stykker.

**Og datoen i listen var altid `updated_at`.** For tolv hundrede importerede noter
er det i aftes, så en note fra 2017 stod som "i går", og den dato, man sorterede
efter, var ingen steder at se. Rækken viser nu den dato, listen er sorteret efter,
og har begge i sit værktøjstip.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/store/notes_test.go

@@ -333,3 +333,39 @@ func TestATagFindsItsProjectWhateverTheCase(t *testing.T) {
 		t.Error("a note title did not match itself")
 	}
 }
+
+// En søgning skal svare med det, der passer bedst, øverst.
+//
+// Den sorterede efter `updated_at`, hvilket var usynligt med ti noter og
+// ubrugeligt med tolv hundrede: de blev alle importeret samme aften, så datoen
+// siger ingenting, og loftet skar så listen af ved halvtreds tilfældige rækker.
+// At søge "Tesla" svarede med en note om nginx først og noten, der hedder "Tesla
+// Model Y", bagefter — hvilket læses som en søgning, der ikke virker, fordi det
+// fra brugerens plads er præcis dét.
+func TestSearchAnswersWithTheBestMatchFirst(t *testing.T) {
+	db, userID := sealedStore(t)
+	ctx := context.Background()
+
+	// Skrevet i den rækkefølge, der ville give det forkerte svar: den, der kun
+	// nævner ordet i kroppen, gemmes sidst og har derfor den nyeste dato.
+	for _, body := range []string{
+		"# Tesla Model Y\n\nBilen selv.\n",
+		"# Ladestandere\n\nNoter om Tesla og andre mærker.\n",
+		"# nginx proxy manager backup\n\nEn konfiguration. Tesla nævnes i forbifarten.\n",
+	} {
+		if err := db.SaveNote(ctx, &Note{CreatedBy: userID, Body: body}); err != nil {
+			t.Fatal(err)
+		}
+	}
+
+	found, err := db.SearchNotes(ctx, "Tesla", 10)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if len(found) != 3 {
+		t.Fatalf("fandt %d noter, ventede 3", len(found))
+	}
+	if found[0].Title != "Tesla Model Y" {
+		t.Errorf("øverst stod %q; den note, der hedder det, man søgte efter, skal stå først", found[0].Title)
+	}
+}