Bug: Supra resolution fails when antecedent citation lacks captured party names

[medelman17]

Description

Supra citations fail to resolve to their antecedent full citations when the full citation's matchedText doesn't include party names. The fuzzy party matcher compares the supra's party name (e.g., "Smith") against the full citation's matched text (e.g., "500 F.2d 123"), resulting in low similarity scores that fall below the default threshold.

Reproduction

import { extractCitations } from 'eyecite-ts'

const text = `In Smith v. Jones, 500 F.2d 123, 125 (9th Cir. 2020), the court held that the statute was unconstitutional. Smith, supra, at 130.`

const citations = extractCitations(text, { resolve: true })

// citations[0]: { type: 'case', matchedText: '500 F.2d 123' }
// citations[1]: { type: 'supra', matchedText: 'Smith, supra, at 130' }
// citations[1].resolution: { failureReason: 'Party name similarity 0.63 below threshold 0.8' }

The supra citation correctly identifies "Smith" as the party reference, but the antecedent full case citation's matchedText is "500 F.2d 123" — it doesn't include the party names "Smith v. Jones" that appear in the surrounding text.

Root Cause

The resolution engine appears to be comparing supra party names against the full citation's matchedText field rather than looking at the broader text context around the antecedent citation. Since matchedText only spans the volume-reporter-page portion (e.g., 500 F.2d 123), the party name comparison yields low similarity.

Related Issues

• Feature: Expose plaintiff/defendant as citation fields #12 (Expose plaintiff/defendant as citation fields) — if party names were extracted as structured fields on full citations, the supra resolver could match against those fields directly instead of relying on matchedText.
• • Feature: Full citation span including plaintiff and parenthetical #9 (Full citation span including plaintiff and parenthetical) — expanding the matched span to include party names would also address this.

Suggested Fix

The resolver should look for party names in the text surrounding the antecedent citation, not just within its matchedText. A reasonable heuristic: scan backwards from the citation start position for a v. pattern within ~100 characters and extract party names from there. This would bridge the gap until #12 is implemented.

Alternatively, lowering the default partyMatchThreshold from 0.8 to something like 0.6 might help as a temporary workaround, though that risks false positive matches.