Fixtures: two expected lines point next to the offending YAML entry

[dvejsada]

Summary

The corpus gives a line for almost every expected diagnostic, and the README makes location normative ("Only rule id, severity, and location are normative"). The frontmatter fixtures consistently point at the offending node's own line, at whatever depth it is:

Fixture	Line	What is there
side-name-duplicate	10	- name: parties, the duplicate side's entry
representative-name-empty	10	- name: "", the representative's entry
attachment-id-collision	4	- id: scope, the attachment's entry
party-type-invalid	7	type: corporation, the key

Two cases point next to their entry instead:

• party-name-duplicate/basic expects line 10, - name: clients, which is the second side. The duplicate party is its entry - name: acme at line 12. The fixture looks adapted from side-name-duplicate, where line 10 is correct, without accounting for the extra nesting level.
• attachment-id-duplicate (main.lgd) expects line 8, title: "Schedule A again". The duplicate id is the entry - id: schedule-a at line 7, as in attachment-id-collision.

verify.py checks only that a line is in range and not blank, so it can't catch this.

Proposal

• Set party-name-duplicate/basic.expected.json to "line": 12.
• Set attachment-id-duplicate/expected.json to "line": 7.
• Optionally, state the convention in fixtures/README.md:
  • a frontmatter diagnostic is reported at the offending node, which is a mapping key or a list entry's - line;
  • a missing key is reported at the key that holds it (for example amends: for a missing amends.title), or at the frontmatter's first key.

Context

ForLegalAI/legaldown-validator#27 adds lines to every diagnostic and now asserts each fixture's line. Everything else in the corpus matches. The validator reports the entries' own lines (12 and 7) and records these two cases as disputed until the corpus is settled.