feat(score): validity-aware phone completeness credit

[s-annam]

Summary

Plumbs `libphonenumber` `isValid()` from the extraction layer all the way to the anonymous scorer so a parsed-but-invalid phone earns half completeness credit instead of full. Valid phones and absent phones are unchanged.

Three-tier scoring: valid/unknown validity → full credit; phoneIsValid===false → passed: false, credit: 0.5 (still surfaces in `missing`); absent/below confidence floor → zero credit. Mirrors the redacted-dates half-credit pattern.

Closes #70

What changed

Plumbing (scorer cannot import phone.ts — entry-chunk budget):

• contact.ts: add phoneIsValid? to ContactExtractionResult; scan() sets it from phoneResult.isValid; extractContact() carries it from whichever scan supplied the phone.
• types.ts: add phoneIsValid? to HeuristicParsedResume.
• openresume.ts: spread phoneIsValid into parsed when phone is present.
• regex-fallback.ts: set parsed.phoneIsValid in the Tier 1.5 phone block.

Scoring (score.ts):

• Add phoneIsValid? to AnonymousAtsScoreInput.parsed.
• Add PHONE_INVALID_CREDIT = 0.5 constant.
• Special-case phone in the contact-field loop with three tiers.
• Bump ATS_SCORE_ALGO_VERSION 1.3 → 1.4 + changelog entry.

Tests: 4 new score.test.ts cases; 25 corpus expected.json re-baked (only algoVersion and new phoneIsValid key changed — no completeness scores shifted, confirming all fixtures use valid 555-0100..0199 numbers per PII policy).

Test plan

• npm run typecheck clean
• npm run test green (722/722)
• Manually verified in npm run dev / npm run preview

[rohithgollapalli]

Review

Plumbing is clean and the scorer change is correct. The 25-fixture rebake touching only algoVersion + the new key confirms no score shifts. Two findings:

1. src/lib/edit/apply-overrides.ts:204-214 — editing the phone carries a stale phoneIsValid

nextParsed is built with { ...parsed } (line 196), copying the original phoneIsValid. The contact-override loop overwrites nextParsed.phone (line 212) but never refreshes phoneIsValid.

Scenario: a resume parses with an invalid phone (phoneIsValid: false → half credit, "phone" in missing). The user fixes the number in the editor → App.tsx re-grades with the override output → phone is the new valid string but phoneIsValid is still false, so the scorer keeps awarding half credit and keeps listing phone as missing. The correction has no effect on the score.

Fix: when phone is overridden, delete nextParsed.phoneIsValid (falls back to backward-compatible full credit) — mirroring the empty-string clear path.

2. src/lib/score/score.test.ts:722 — half-credit test's upper bound is too weak

expect(invalidResult.completeness.score).toBeLessThanOrEqual(validResult.completeness.score) passes even if invalid phones were granted full credit — i.e. the test stays green if the feature breaks in exactly its core direction. Only the > absentResult assertion has teeth.

Fix: use toBeLessThan(...) (here 29 < 30, so it holds strictly).

Finding #1 is the substantive one — a real gap in the edit re-grade path this PR introduces.

🤖 Generated with Claude Code

[s-annam]

Both review findings addressed in 1c7f5c8:

1. apply-overrides.ts stale phoneIsValid — applyOverrides now deletes nextParsed.phoneIsValid whenever the phone field is overridden or cleared, so a corrected phone re-grades as validity-unknown (backward-compatible full credit) instead of carrying the old false. Added two regression tests (override path + clear path).
2. Weak upper bound — toBeLessThanOrEqual → toBeLessThan on the half-credit case.

Typecheck clean, 724/724 green.