fix(editor): traject-eigen indexscan resolvet token strikt en meldt scan-falen per source

[tdjager]

Closes tdjager/development#6

Wat

Een via de promote-flow (#952) naar de traject-repo geschreven wet laadde op een deployment zonder per-repo servertoken niet uit de traject-eigen source (priority 0), maar viel stil terug op het centrale corpus — de traject-source toonde alleen law_count: 0.

Root cause (token-hypothese bevestigd)

De hypothese uit het ticket klopt op codeniveau en is in een integratietest 1-op-1 gereproduceerd:

• De promote schrijft met het user-OAuth-token (token_override via user_write_token_for_backend) — die kant slaagt.
• De server-side indexscan van dezelfde repo (CorpusRegistry::index_all_sources_async → index_one_source) las met een ander resolutiepad: resolve_token_for_source mét legacy CORPUS_GIT_TOKEN-fallback, waar push/backendconstructie strikt resolven (resolve_token_strict).
• Zonder geconfigureerd CORPUS_AUTH_<owner-repo-slug>_TOKEN (en zonder bruikbaar legacy-token) scant de server een privé-repo unauthenticated → Trees-API 404 → source faalt te enumereren → lege index → wet resolvet uit de seed (priority 2). Precies het waargenomen prod-gedrag; traject_own_index_test.rs reproduceert het zonder netwerk (wiremock).

Naast de deploy-config-kant (ontbrekende env-var; de exacte naam staat als bevinding op het ticket — bewust niet in deze publieke PR) zat er dus ook een echte code-inconsistentie: scan en push konden over verschillende tokens beschikken, en de legacy-fallback op het scanpad zou het centrale token naar een user-gekozen repo sturen — het exfiltratie-lek waarvoor resolve_token_strict juist bestaat, maar dan op het leespad.

Fix

• Source.strict_auth (gezet voor writable-own rows, ook in de pipeline-worker) laat élk token-resolutiepad — indexscan, favorites-fetch, backendconstructie — dezelfde strikte regels volgen via de nieuwe auth::resolve_source_token.
• Scan-falen is niet langer stil: index_all_sources_async geeft per gefaalde source de fout terug (SourceIndexFailure); GET /api/trajects/{ref}/sources (en /api/sources) tonen die als index_error per source, zodat law_count: 0 mét fout te onderscheiden is van een écht lege repo.
• De bestaande tracing::error! bij een gefaalde writable-own-scan draagt nu de onderliggende fout mee; de "resolved NO token"-diagnostiek benoemt naast pushes ook reads/scans.

Tests

• Nieuw packages/editor-api/tests/traject_own_index_test.rs: (1) prod-repro — promote slaagt, onleesbare traject-repo → fallback naar seed (priority 2) + index_error op de source; (2) happy path feat(editor): wet zoeken in centraal corpus, promoten naar traject en harvest-fallback via taken #952 — leesbare repo → gepromote wet in de traject-index op source_priority: 0, law_count: 1, geen index_error.
• Unit tests voor resolve_source_token (strict vs. legacy) en build_source_summaries (index_error).
• just check groen (format, clippy, check, validate, unit tests, harvester-, pipeline-, admin- en editor-api-tests; testcontainers via TESTCONTAINERS_HOST_OVERRIDE).

[tdjager]

CI: alles groen behalve Security Audit — die faalt op npm audit (brace-expansion, GHSA-3jxr-9vmj-r5cp), niet op cargo-deny (advisories ok, bans ok, licenses ok, sources ok). Deze PR wijzigt uitsluitend Rust; dezelfde job was 13u eerder groen op main op exact het branch-punt (5c1272c), dus dit is een nieuw upstream-advisory dat elke run nu raakt en losstaat van deze wijziging.

[tdjager]

Review-pipeline doorlopen: geen codebevindingen — strict_auth/resolve_source_token dekt alle source-gedreven resolutiepaden consistent, index_failures wordt op alle snapshot-paden correct gevuld/geleegd, en de testdata blijft netjes fictief. Enige toevoeging: lockfile-bump brace-expansion → 2.1.2 (b596e36) waarmee de Security Audit weer groen is (GHSA-3jxr-9vmj-r5cp, upstream advisory los van deze wijziging). Alle checks groen; claude-review kwam twee rondes zonder bevindingen terug.