fix(okr): fase D akse-B — index-rekkefølge fra kaller, ikke fra disk

Vår alfabetiske `.sort()` i okf-index.mjs lå på akse B (ingest-spec.md:178-181),
som krever manifestets ekstraksjonsrekkefølge fra kalleren og eksplisitt forbyr
«filesystem enumeration order». Ruling-dokumentet (portfolio-optimiser-commons
docs/plan/2026-07-25-ordering-axes-ruling.md §4 @ a67a243) navngir alfabetisk
sortering som deterministisk FEIL på denne aksen: B ber ikke om *en*
deterministisk rekkefølge, den ber om *kallerens*.

Kontrakt (operatør-valgt), implementert i orderEntries():
1. navn som alt står i indeksen  -> beholder linjerekkefølgen (§6 «preserved
   byte for byte»)
2. nye navn med kaller-rang      -> kallerens ekstraksjonsrekkefølge
3. nye navn uten kaller-rang     -> alfabetisk

(3) er en dokumentert genesis-fallback, ikke en B-etterlevelse: CLI-en tar kun
en katalog og har ingen kaller-liste å tre gjennom, og alternativet — rå
readdirSync-rekkefølge — er nettopp det B forbyr. Fallbacken gjelder bare ved
genesis; så snart en indeks finnes vinner (1), så et alfabetisk valg overstyrer
aldri en rekkefølge en kaller har etablert.

§5 i rulingen: den som arver B arver §6-idempotensen med den. `order` er derfor
KUN rangering — medlemskapet leses fortsatt fra disk (akse A, :175-177), så en
sti i lista kan aldri opprette eller gjenopplive en fil, og et gate-discardet
dokument kan ikke snike seg inn i indeksen. parseExistingIndex bærer nå
linkOrder eksplisitt framfor å hvile på JS-objekters innsettingsrekkefølge.

innboks-ingest.mjs trer sin faktiske ekstraksjonsrekkefølge gjennom; uten det
ville fiksen vært et ubrukt API.

Tester: 182 -> 187. Alle fem nye verifisert røde mot mutant (orderEntries ->
`[...names].sort()`), de 39 øvrige grønne under samme mutasjon. Ende-til-ende-
testen diskriminerer ved at dokumentrekkefølgen (Zulu før Alfa) er den motsatte
av den alfabetiske.

Ingen versjonsbump; release avventer operatør-go.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EaQkAtvpNCLxWkjdEJ11vx

tests/innboks-ingest.test.mjs

@@ -244,3 +244,32 @@ test('ingest: binaer-original (.docx/.pdf) passerer strict -- pekerfil uten lenk
     assert.deepEqual(manifest(bundleRoot), m1, 'binaer-ingest idempotent');
   });
 });
+
+// AKSE B ende-til-ende (ingest-spec.md:178-181 + §6). Primitivet er dekket i
+// okf-check.test.mjs; DENNE testen beviser at ingest faktisk TRER sin
+// ekstraksjonsrekkefoelge gjennom til indeksen -- uten den ville fiksen vaert
+// et ubrukt API. Diskriminatoren er at dokumentrekkefoelgen (Zulu foer Alfa)
+// er den MOTSATTE av den alfabetiske, saa en regresjon til .sort() er synlig.
+test('akse B ende-til-ende: index foelger ekstraksjonsrekkefoelge, ikke alfabetisk', async () => {
+  await withBundle(async ({ bundleRoot, inbox }) => {
+    writeFileSync(
+      join(inbox, 'notat.txt'),
+      '# Notat 2026\n\nIntro.\n\n## Zulu tema\n\nZulu-tekst.\n\n## Alfa tema\n\nAlfa-tekst.\n',
+    );
+    await ingestInbox(inbox, bundleRoot);
+
+    const links = readFileSync(join(bundleRoot, 'dokumenter', 'index.md'), 'utf8')
+      .split('\n')
+      .map((l) => l.match(/^\*\s*\[[^\]]*\]\(([^)]+)\)/))
+      .filter(Boolean)
+      .map((m) => m[1]);
+
+    assert.deepEqual(
+      links,
+      ['notat-2026.md', 'zulu-tema.md', 'alfa-tema.md', 'notat.kilde.md'],
+      'index-lenker skal staa i dokumentets ekstraksjonsrekkefoelge',
+    );
+    const alphabetical = [...links].sort();
+    assert.notDeepEqual(links, alphabetical, 'testen er kun gyldig hvis den skiller seg fra alfabetisk');
+  });
+});