importer: fallback to legacy import path when data is sorted

## Summary

When the distributed merge pipeline is enabled for IMPORT, we should detect when the incoming data is already sorted and fall back to the legacy import path. Distributed merge adds overhead (map → merge → ingest phases, intermediate SSTs to `nodelocal://`) that isn't beneficial when data is already in order — in fact, #161887 measured a ~20% regression on sorted data for the index backfill case.

We already solved this for index backfill in #161887: since the backfiller knows the schema of the index being created, it can determine from the primary key ordering whether the output data will be sorted and skip distributed merge entirely.

## Challenge

Import is trickier than index backfill because we don't necessarily know ahead of time whether the incoming data is sorted. The data comes from external files (CSV, AVRO, etc.) and the ordering depends entirely on how the user prepared it. We can't simply inspect the table schema to determine sortedness the way we can for index backfill.

## Possible Approaches

One idea is **early runtime detection**: observe the first portion of incoming data and check whether it arrives in sorted key order. If it is sorted after processing some initial window of rows, fall back to the legacy import path — provided we haven't progressed too far into the distributed merge pipeline to make a switch costly.

This raises several design questions that need thought:

- **How much data do we need to sample before deciding?** Too little and we risk a false positive (data happens to start sorted but becomes unsorted). Too much and we've already committed significant work to the distributed merge path.
- **At what point is it too late to switch?** If we've already written intermediate SSTs and started the merge phase, falling back is expensive. The detection and decision likely need to happen during (or immediately after) the map phase.
- **What about partially sorted data?** Data could be mostly sorted with a few out-of-order segments. Is there a threshold that still makes legacy worthwhile?
- **Per-node vs. global decision?** Each import processor sees a subset of the data. Sortedness on one node doesn't guarantee global sortedness. The decision may need to be coordinated.

## References

- #161887 — the index backfill precedent: "bulkmerge: avoid degrading sorted data" (measured ~20% regression, solved by detecting sortedness from index schema)
- #156660 — original integration of distributed merge into IMPORT
- #167837 — mode-based cluster setting for `sql.import.distributed_merge` with fallback (related; the mode setting should accommodate this as an additional fallback condition)

Epic CRDB-62564

Jira issue: CRDB-62669