Remove --unlink-first and --recursive-unlink from tar extract

What does this MR do and why?

Removes the --unlink-first and --recursive-unlink flags from the tar extract command used during backup restore. These flags cause restore to fail on RHEL/EL9+ systems where a patched GNU tar (RHSA-2026:0067) makes unlink(".") return EINVAL on the ./ root entry in backup archives.

The flags are redundant because the Rails restore path already moves all existing files to a timestamped backup directory via backup_existing_files_dir before tar extraction runs. Tar's default overwrite behavior is sufficient.

This MR supersedes !231770 (closed). All credit for the fix goes to @hhubert14 — his commit is included here with authorship preserved. I moved the change to a branch on the canonical project to unblock merging (the original MR went idle waiting on review logistics), added the Changelog trailer, and addressed the outstanding test-coverage review feedback by adding a negative assertion that guards against reintroducing the flags.

The change was already validated:

• Maintainer approval on the original MR by @balasankarc, who confirmed the original motivation for the flags (nested storage paths, gitlab-foss#42593 (closed)) was separately fixed in omnibus-gitlab!3447 (merged)
• End-to-end validation plan executed by @mkozono (see issue description)
• Multiple customers confirmed the fix works by hot-patching tar.rb in place

References

• Closes #587492 (closed)
• Supersedes !231770 (closed)
• Red Hat advisory: https://access.redhat.com/errata/RHSA-2026:0067

How to set up and validate locally

1. Run the backup targets spec:

   bundle exec rspec spec/lib/backup/targets/files_spec.rb

2. Verify all 29 examples pass with 0 failures.

3. For end-to-end validation on a RHEL/EL9 system with patched tar (tar-1.34-9.el9_7 or later), run a full backup/restore cycle and confirm no Cannot unlink errors occur. A Docker-based validation runbook is in the issue description.