fix(verification): bind verified.type_check records to file content

[alpibrupa]

Summary

• verification.Record had no binding between a recorded pass and the content it was a pass of — only kind + target. Since the log is append-only and project-scoped (by design, per feat: auto-attestation pipeline — write trail records when verification passes #32), a passing record from an earlier session or a since-reverted edit stays in .lex/verified.jsonl forever, and task_spec.lex's old seen/seen_on only checked whether any matching record existed, never whether it still applied.
• Reproduced live in verified.type_check has no binding to file content, so a stale pass outlives the edit that broke it #91: a stale verified.type_check record from an unrelated, older, successful run satisfied a task-spec criterion for a file whose current content failed lex check in the very same report.
• Record gains sig :: Str — a sha256 of the target's content at the moment the record was made:
  • linter.record_verified (the write/edit implicit-check path from Write's implicit lex check never reaches the attestation trail, so a correct fix can still fail verification #90) hashes the file right after it just passed lex check — the freshest possible signal.
  • verification.harvest (the session-log path for the standalone lex_check tool, via dispatch_one_traced) hashes the target right after the turn that produced the record, since the session-log event itself never carried file content.
  • A record naming a target with no sig (legacy, or unhashable), or with a sig that no longer matches the target's current bytes, does not count as seen.
• task_spec.lex's seen/seen_on become presence/presence_on, returning a three-state Absent | Fresh | Stale instead of a bool — a stale record now reports "a record exists but no longer matches the file's current content — re-run the check," distinct from "no record at all," so a reader knows which situation they're in.

Fixes #91

Test plan

• lex check on all three modified files, plus a full repo sweep (lex check over every tracked src/ file)
• lex fmt --check src/
• lex test (4/4 passing)
• lex doc-sync --check
• Live repro of verified.type_check has no binding to file content, so a stale pass outlives the edit that broke it #91's exact scenario in a fresh git worktree: wrote a file via the real write tool (fresh, hash-backed record) → task spec reports SATISFIED; then edited the file out of band (bypassing write/edit, simulating a stale leftover record) → task spec now reports NOT SATISFIED with "a verified.type_check record exists for verify_target.lex but it no longer matches the file's current content — re-run the check", correctly distinguishing "stale" from "never checked"

🤖 Generated with Claude Code