bulk: synchronous statements surface the lease-relocation marker to the client

**Summary:**
When a synchronous bulk statement with an execution-locality filter is issued
from a gateway that doesn't match the filter, the coordinator relocates and the
job's `Resume` returns the lease-relocation marker (`jobs.IsLeaseRelocationError`).
On the synchronous path this marker is returned to the client as an error even
though the job continues and completes on the destination node — the statement
appears to fail while actually succeeding.

**Background:**
IMPORT now waits through this: on the marker it calls `JobRegistry.WaitForJobs`
and reports results from the job's persisted progress. BACKUP/RESTORE still return
the marker to the client (`backup_planning.go`, `restore_planning.go` — same
`AwaitCompletion` -> return err pattern).

**Proposed work:**
- [ ] Apply the same wait-through to synchronous BACKUP/RESTORE.
- [ ] Persist IMPORT's INSPECT job ID so the relocation path can report a
non-NULL `inspect_job_id` (currently NULL there, since the INSPECT job runs
on the destination and its ID isn't persisted on the import job).

Epic CRDB-65504

Jira issue: CRDB-66931

Read backup_planning.go and restore_planning.go around the synchronous AwaitCompletion-to-return-err path, then compare it with IMPORT's JobRegistry.WaitForJobs handling. Done means synchronous BACKUP/RESTORE wait through lease relocation instead of surfacing the marker, and the relocation path persists IMPORT's INSPECT job ID rather than reporting NULL.

Written by the indexing model from the issue text.