# Fix Dedicated Restore Progress Mapping Execution Plan

## Analysis

### Problem statement
The dedicated restore progress from regional control-plane is not fully exposed in dataflow-service because progress details are dropped during conversion in `pkg/regional-api/br.go`.

### Impact scope
- Affected path: restore progress sync in workflow action reads `cloudv1.Restore.Status.Progresses`.
- Current behavior: only `Status.Phase` is mapped; `Status.Progresses` is empty.
- External symptom: restore progress can remain 0 or missing step details.

### Keep / change table
| Area | Keep | Change |
|---|---|---|
| Restore status phase mapping | Existing `restoreStatusToPhase` behavior | None |
| Restore progresses mapping | N/A | Add conversion from `clusterv1.Restore.Progresses` to `cloudv1.RestoreStatus.Progresses` |
| Tests | Existing BR facade tests | Add targeted unit tests for restore conversion |

## Execution Steps

1. Add restore progress conversion in `pkg/regional-api/br.go`.
   - Implement helper to convert protobuf restore progress list to cloud restore progress list.
   - Wire helper into `GetRestore` return object.

2. Add unit tests in `pkg/regional-api/br_test.go`.
   - Add test for `GetRestore` mapping of phase + progress items.
   - Add test for conversion helper behavior with empty/nil inputs.

3. Verification.
   - Run: `go test ./pkg/regional-api -run TestGetRestore -count=1`
   - Run: `go test ./pkg/regional-api -run TestConvertRestoreProgressesToCloud -count=1`
   - Run: `go test ./pkg/regional-api -count=1`
   - Success criteria: all commands exit 0.

4. Prepare PR.
   - Create commit with focused message.
   - Push branch and open PR against `master`.

## Risk Assessment
- Low risk: localized read-path conversion only.
- Main risk: timestamp conversion mismatch (protobuf timestamp to `metav1.Time`).
- Mitigation: unit tests assert step, percentage, and timestamp mapping.