[matt-edmondson]

Fixes #66

What changed

MetadataFile.FindLocation(anchor, needle) only searched forward from the anchor. JSON objects have no key order, so when the needle's key came before the anchor's key in the same entry ({"base":"Meter","name":"Foot"}), the search found the needle in a later entry, or fell back to the first unscoped match in an earlier one.

The search now runs in this order:

1. after the anchor, inside the JSON object that encloses it
2. before the anchor, inside that same object
3. forward from the anchor, past the object (the old behaviour)
4. anywhere in the file (the old fallback)

The enclosing object is found with a forward scan from the start of the file. That scan tracks string state and nesting, so braces inside strings and nested objects written before the anchor are not mistaken for the entry's braces. IndexOfToken gains an end-bounded overload for this.

Tests

• New: the issue's Foot/Yard example returns line 1. The Inch/Foot variant returns the Foot entry instead of falling back to Inch. A third case puts {/} inside a string and a nested object before the anchor.
• Without the fix all three new tests fail. With it they pass.
• Existing tests still pass, including anchor-first order, the substring cases from MetadataFile.FindLocation(anchor, needle) points at the wrong entry when the anchor or needle is part of a longer name ("Meter" lands on "SquareMeter") #33/Find a whole JSON string before a substring in FindLocation [patch] #63, and the needle-absent fallbacks. Full suite: 83/83.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
88.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud