fix(backup): contain restore file paths within the handler root

[alhudz]

Description

The path field of a backup manifest is read back from the backup location (readMasterManifest) and used as-is during restore.

1. restore_map.go joins manifest.Path with the backup file name and streams it through fileHandler.Stream -> os.Open(filepath.Join(rootDir, prefix, path)).
2. getManifestsToRestore joins the same manifest.Path for FileExists, and the s3/minio handler builds object keys the same way in getObjectPath.

JoinPath/getObjectPath do not contain the relative path, so a manifest left in the backup target with path set to ../../.. steers those reads outside the handler root. The fix sits in the handlers because that is the single choke point every backup/restore file op goes through.

Repro: worker/backup_handler_test.go (fails before, passes after).
Expected: the resolved path stays under the handler root.
Actual: JoinPath("../../../../etc/passwd") returns /etc/passwd; getObjectPath returns ../../etc/passwd.
Fix: cleanRelPath anchors the path at the root and drops a leading separator / .. before the join; JoinPath (file + s3) and getObjectPath all route through it.

Checklist

• The PR title follows the
  Conventional Commits syntax, leading
  with fix:, feat:, chore:, ci:, etc.
• Code compiles correctly and linting (via trunk) passes locally
• Tests added for new functionality, or regression tests for bug fixes added as applicable

[alhudz]

gentle ping

[shiva-istari]

Thanks for the fix, @alhudz !

I went through the changes and they look good to me. It would be nice to add a table-driven test for cleanRelPath covering a few edge cases like "", ".", a/../b, absolute paths, and paths with trailing or duplicate separators. I think that would make future regressions less likely.

In addition, an integration test would be valuable to verify the end-to-end behavior and help prevent regressions in the future.

Other than that, LGTM. Happy to see this merged.