[DIT-13463]: Stable occurrence index on scan candidates

[laurakoye]

Overview

Adds occurrence_index to scan candidates: which repeat this string is within its file, counting from 0 in source order.

If a file has three "Save" strings, only the line number tells them apart today — and line numbers move whenever someone adds an import. The index doesn't, so a code link can still say which occurrence it points at after the file shifts.

• New assignOccurrenceIndexes(hits) in lib/src/scan/extract.ts, exported so it can be unit tested.
• It sorts by (line, column) first, which is the point of the PR. The JS extractor emits hits grouped by node kind (lang/extractors/javascript.ts:37), not source order, so counting them as they arrive gives an index that changes between runs of an unmodified file. Sorting happens on indices internally, so emitted candidate order is unchanged.
• occurrence_index added to DittoScanCandidateSchema.

Nothing server-side is needed to merge — zod strips unknown keys, so the field is ignored on arrival for now. A ditto-app follow-up adds it to PtdCandidateSchema, where the code link write will read it.

Context

DIT-13463, part of DIT-13405.

A code link identifies a hardcoded string by (file, value, occurrence index) — never by line number, which is display-only. This is the last of those three fields. Schema design.

Screenshots

None — extraction output only.

Test Plan

Testing successfully completed locally via:

• yarn test lib/src/scan — 136 tests pass, 6 new
• Scan twice across an edit, below

Scan v0-demo, edit it, scan again. --local skips auth, upload and classification, so no server or token needed.

yarn scan ../v0-demo --local --out-dir /tmp/a

In v0-demo/src/features/payments/SendMoney.tsx, add an import and a const above the component so every line shifts down, then add one more t("send.title") below the two already there.

yarn scan ../v0-demo --local --out-dir /tmp/b

for f in a b; do
  jq -r 'select(.location.file | test("SendMoney")) | select(.value_raw | test("send\\.")) | "\(.location.line)  #\(.occurrence_index)  \(.value_raw)"' /tmp/$f/candidates.ndjson
done

before                          after
14  #0  "send.title"            17  #0  "send.title"
19  #0  "send.recipientLabel"   22  #0  "send.recipientLabel"
32  #1  "send.title"            35  #1  "send.title"
40  #1  "send.recipientLabel"   43  #1  "send.recipientLabel"
                                62  #2  "send.title"     ← the added one

Every line moved by 3. Every index stayed. The new occurrence is #2 because it comes after the others in the file.

Known limit: add that third t("send.title") above the existing two instead and it becomes #0, renumbering the rest. Keyed strings survive that via i18nKey; hardcoded ones fall through to the value-in-file rung during reconciliation. The index only has to be stable against edits elsewhere in the file, not against inserting a new copy of itself.

[laurakoye]

Closing since this PR should really branch off of text-extract