backup: TrailingMetaCallback in restoreDataProcessor uses stale context for tracing metadata

## Summary

The `TrailingMetaCallback` registered by `newRestoreDataProcessor` captures the constructor's `ctx` parameter in its closure and passes it to `ConstructTracingAggregatorProducerMeta`. This context does not carry the processor's tracing span, which is created later during `StartInternal`. As a result, the span totals emitted in trailing metadata may reference the wrong span hierarchy, leading to inaccurate trace statistics.

## Severity

Low. This affects observability/diagnostics only, not data correctness or restore reliability.

## Evidence

- `pkg/backup/restore_data_processor.go:133-167` — closure captures constructor `ctx`
- `pkg/backup/restore_data_processor.go:157` — passes stale `ctx` to `ConstructTracingAggregatorProducerMeta`
- `pkg/backup/restore_data_processor.go:913` — `Next()` correctly uses `rd.Ctx()` for comparison

## Additional Findings

1. **Dead code:** `openSSTs` method is only called from tests, not production. Production uses `openSSTsForFiles`.
2. **Panic recovery reformatting:** `cancelWorkersAndWait` catches structured `verboseError` panics and re-panics with `fmt.Sprintf(...)`, losing structured error info.

## Suggested Fix

Extract tracing metadata *before* calling `ConsumerClosed()` so the processor's span is still active.

_This issue was found via automated deep static analysis._

Jira issue: CRDB-62035