Ad-hoc single-maintainer LFX profile check (staff UI action)

## Classification
Enhancement (new feature)

## Problem

The only way to refresh one maintainer's LFX linkage today is a full
enrichment run, and the enrich-all pass skips anyone who already has any lfx
observation row — so a stale `unmatched` verdict is permanent for that
maintainer until this exists.

## Proposal

- Staff-only action on the maintainer page: "Check LFX profile now" — runs
the 3-tier lookup (GitHubID → Email → Username) for that one maintainer,
writes/refreshes the lfx observations, and updates `maintainers.lfx_user_id`
per the newest-profile rule.
- Must use a single, shared LFX resolution path — do not add a third parallel
implementation of LFX identity resolution.
- LFX token handling: tokens expire in hours and are pasted per request,
never stored server-side — reuse the same paste-a-token UX as the
enrichment run form.
- Surface the result inline (matched profile, confidence, tier used) and in
the audit log, including the *per-tier* outcome rather than a bare verdict,
so staff can see why a lookup missed.

## Motivating case (anonymized, from production, 2026-09-08)

One maintainer record carried a Salesforce Lead ID in `lfx_user_id` from a
legacy write path, alongside two stale `unmatched` lfx observations recorded
by pre-pagination-fix code. Because the enrich-all pass skips any maintainer
with an existing lfx row, this record was permanently excluded from
re-enrichment — even though current code's tier-3 (username) search would
find the correct profile immediately. It was resolved manually via a direct
database update; this feature exists so that class of fix never again
requires direct database access.

## Relationships

- Should be built on a single LFX resolution path — directly related to #124
(modularize `lfxIdentityResolver` into one shared implementation instead of
the current duplicated resolvers).
- The "newest-profile rule" this action relies on is entangled with #159
(`chosen` match status has no consumer / fill-only canonical promotion
never landed) — worth confirming how canonical-field promotion should work
before or alongside this feature.
- The motivating case's "stale evidence permanently blocking a correct future
match" is the same failure class fixed for the general enrichment pass by
#158 (closed); this feature is the manual/staff-triggered equivalent for a
single maintainer.
- Also related to #165 (observation getters can return the wrong row in a
multi-profile group) — this feature's result display must not inherit that
ordering bug.

Start with the existing lfxIdentityResolver and enrichment run form, then trace how the maintainer page and audit log expose enrichment results. Review #124, #159, and #165 before choosing the shared resolution and newest-profile behavior. Done means a staff-only single-maintainer check refreshes observations, shows the matched profile, confidence, tier outcomes, and records those outcomes in the audit log.

Written by the indexing model from the issue text.