pkg/lightning: reorganize global sort and local backend code around ingest APIs

## Enhancement

### Background

Some code for global sort and local backend currently lives under `pkg/lightning`. These components are no longer Lightning-only concepts: they are generic building blocks around the ingest API / ingestor path and may be shared by import-related code outside the Lightning package boundary.

Keeping these generic pieces under Lightning-specific packages makes the ownership and terminology harder to follow for code readers and automation agents. It also makes future PRs more likely to preserve package names and concepts that no longer describe the implementation accurately.

### Goal

Use this issue as the tracking issue for PRs that gradually reorganize and refactor the global sort and local backend code so the package layout, naming, and documentation match the more generic ingest / ingestor responsibility.

### Scope

- Move or split global sort and local backend code out of Lightning-specific locations when a clearer ingest / ingestor-oriented package boundary is available.
- Keep behavior stable while changing package ownership, imports, and names.
- Align names, comments, and package documentation so the concepts are consistent for code readers and agents.
- Link incremental PRs to this issue instead of doing a single broad refactor.

### Non-goals

- No user-facing behavior change is intended by this tracking issue.
- No change to ingest API semantics, import algorithm behavior, or compatibility is intended unless a linked PR explicitly proposes and validates it.
- No broad cleanup unrelated to the global sort, local backend, ingest API, or ingestor package boundary.

### Validation expectations

Linked PRs should include scoped tests for touched packages. If a PR adds, moves, renames, or removes Go files, or adds new top-level Go tests, it should also update the required Bazel metadata with `make bazel_prepare`.