backup: restore missing-stats warning compares rewritten table IDs against source-keyed map

In [`remapAndFilterRelevantStatistics`](https://github.com/cockroachdb/cockroach/blob/004ed2c25fe95c18b4b3cb978c185dc60531ecca/pkg/backup/restore_job.go#L940-L983), the `tableHasStatsInBackup` map is keyed by the backed-up (source) table ID at [L952](https://github.com/cockroachdb/cockroach/blob/004ed2c25fe95c18b4b3cb978c185dc60531ecca/pkg/backup/restore_job.go#L952) — before `stat.TableID` is rewritten to its target ID at [L956](https://github.com/cockroachdb/cockroach/blob/004ed2c25fe95c18b4b3cb978c185dc60531ecca/pkg/backup/restore_job.go#L956). The missing-stats check at [L976](https://github.com/cockroachdb/cockroach/blob/004ed2c25fe95c18b4b3cb978c185dc60531ecca/pkg/backup/restore_job.go#L976) then looks up `desc.GetID()`, which is the rewritten (target) ID, against that source-keyed map.

On cluster restores IDs are preserved, so the lookup happens to work. On non-cluster restores (database/table), descriptor IDs are remapped, so the target ID is never a key in the map and the `!ok` branch is always taken. The result is that the "statistics ... not found in the backup" warning fires for every restored table, including tables whose stats were present and restored correctly — making the check meaningless rather than flagging genuinely missing stats.

The fix is to compare in a consistent ID space (e.g. check membership using the original ID, or key the map by the rewritten ID). This is currently untested; a unit test should cover the non-cluster restore case.

Jira issue: CRDB-65522