One-time reset: wipe and regenerate lfx-source observation rows

## Classification
Task (one-time operational cleanup)

## Decision

Not a blanket wipe of `maintainer_identity_observations` — the test for each
row is "can current code regenerate this, better than what's stored?"

| Source | Verdict | Why |
| --- | --- | --- |
| lfx | Wipe (soft-delete) and repopulate | Actively harmful — any existing row currently exempts a maintainer from re-enrichment; `updated_at` was counterfeited by the orphan-adoption path; pre-pagination-fix `error` rows are fossils from before full pagination existed; fully regenerable by current code (full pagination, honest errors, provenance columns). Last-write-wins already destroyed any history in these rows, so this discards stale/incorrect data, not information. |
| legacy-ref (sanitize-written) | Keep untouched | These rows are not regenerable while the writer is suspended, and are the only record of the legacy ref files. Fate decided by the legacy-ref retirement work. |
| foundation-csv | Leave | Source is heading for legacy status separately; not blocking anything here. |
| dot-project | No action | Refreshed on every sync/run; self-heals. |

## Why lfx rows specifically

Any existing lfx row (even an old `unmatched`/`error` one) currently blocks
a maintainer from being picked up by the enrich-all pass again, so stale rows
are actively harmful rather than merely stale.

## Sequencing rule

The wipe must land *before* a planned observation-history redesign seeds its
"latest state" from existing rows — seeding history from counterfeit
timestamps and pre-provenance rows would bake the inaccuracies in
permanently.

## Procedure

1. Back up the `maintainer_identity_observations` table.
2. Soft-delete all `source = 'lfx'` rows.
3. Repopulate via repeated staff-UI enrichment runs — bounded by the per-run
lookup cap and hours-lived LFX tokens, so this happens over several
sessions; each run drains the "no lfx row" backlog, which shrinks
monotonically.
4. Acceptance check: spot-check a maintainer record known to have been
affected by the stale-row problem and confirm the next run produces a
corroborated match.

Soft-delete, not a hard `DELETE`: this regains enrichability while keeping
the rows for forensics; whether they're ever hard-purged is a retention/PII
decision that belongs to the observation-history redesign, since
soft-deleted rows are still personal data.

## Relationships

- Directly downstream of #161 (closed — LFX search pagination fix) and #158
(closed — stale duplicate profile reconciliation): both fixed the code
paths that produced the fossils this issue cleans up.
- Blocking prerequisite for a not-yet-filed "maintainer observation history"
redesign, per that draft's own sequencing note.