Modularize the lfxIdentityResolver so that mulitple components can depend on it

## Overview

There are currently two ways we can reach out to LFX to update a maintainer's record:

1. cli application
2. the /lfx route on the web app

`lfxIdentityResolver` is duplicated on both these runtime options, extract this to a module to reduce duplication.

## Full details

`lfxIdentityResolver` is the adapter between the dot-project auto-add code and the LFX API.

The dotproject package only knows about this interface in dotproject/auto_add.go:25:

```
type LFXIdentityResolver interface {
ResolveMaintainerIdentity(ctx context.Context, githubHandle, email string) (LFXIdentityResult, error)
}
```
That keeps dotproject independent of the concrete LFX client package. The resolver implementation does the actual LFX lookup:

1. Search LFX by GitHub handle.
2. If no match and email is available, search by email.
3. Accept only a single returned user.
4. Fetch that user’s identities.
5. Mark confidence as exact if the LFX GitHub identity matches the maintainer handle.
6. Store LFID, name, email, company, GitHub user, confidence, reason, and raw LFX payload.

It was duplicated in cmd/web-bff/main.go:4970 because the existing implementation lived inside cmd/dot-project-sync/main.go:350.

Go cmd/... packages are executable entrypoints, not reusable library packages, so web-bff cannot cleanly import cmd/dot-project-sync.

The immediate reason for adding it to web-bff was that the web UI now starts the dot-project sync path directly, using the pasted short-lived LFX PAT and the selected run parameters. To make auto-add work from the web-launched path, the BFF needs an implementation of dotproject.LFXIdentityResolver, not just the standalone CLI.

Treat this duplication as a pragmatic first pass, not the ideal end state. The better shape is probably to move this resolver into a shared package, for example:

- lfx/dotproject or dotproject/lfxresolver
- expose NewIdentityResolver(client lfx.UserSearcher) dotproject.LFXIdentityResolver
- keep dotproject itself free of LFX API details if we want that boundary preserved

That would let both cmd/dot-project-sync and cmd/web-bff use the same resolver and avoid drift in matching semantics. The same argument applies to the foundation CSV loader, which is also now effectively duplicated between the CLI and BFF paths.