fix(rank): rename the location verdict field to location_verdict

"location" meant a place in scraper output and a PASS/FAIL/FLAG verdict
in /rank's persistence - one key, two meanings, in the same store, with
ranking able to overwrite the commute-filter place with "PASS". The
verdict now lives in location_verdict; legacy entries are read
compatibly and migrated on re-write. Also completes the seen_jobs schema
enumeration (F27 Part A): the do-not-drop instruction now names
location_verdict/language_gate/language_note. Review finding F27
(2026-08-19), decision approved by Mads.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -65,6 +65,16 @@ per-file diff commands.
 
 ### Changed
 
+- **`/rank` persists its location verdict as `location_verdict`** - the bare `location`
+  key meant two incompatible things in `seen_jobs.json`: a place (scraper search output,
+  driving the commute filter) and a PASS/FAIL/FLAG verdict (`/rank` Step 4), so ranking
+  could overwrite "Aarhus, Denmark" with "PASS" and no reader could tell which meaning a
+  stored value carried. Legacy entries are read compatibly (a PASS/FAIL/FLAG string in
+  `location` counts as the verdict when `location_verdict` is absent) and migrated on
+  re-write. The `seen_jobs` schema note in `job-scraper/SKILL.md` now also enumerates
+  `location_verdict`/`language_gate`/`language_note`, so its "do not drop any of these
+  fields" instruction finally covers the fields `/rank` calls as important as the score.
+  Pinned by two new tests in `tests/test_rank_command.py`.
 - **`linkedin-search detail` drops the `applyUrl` field** - the extraction regex
   assumed `class=` before `href=` and never matched LinkedIn's real markup (`null` on
   every live posting since the markup ordering differs), and fixing the regex would only