[GH] (texera/main): Workflow run "Release Auditing" is working again!

[GitBox <gi...@apache.org>]

The GitHub Actions job "Release Auditing" on texera.git/main has succeeded.
Run started by GitHub user github-merge-queue[bot] (triggered by github-merge-queue[bot]).

Head commit for run:
02a04d86a57de031106159e9f688c309b4c5b781 / Yicong Huang <17...@users.noreply.github.com>
ci: harden backport cherry-pick against package/directory renames (#6964)

### What changes were proposed in this PR?

The backport automation already uses `git cherry-pick` (a 3-way merge
with rename detection), not `patch`/`git apply`, so a renamed file is
normally followed to its new path automatically. But every `cherry-pick`
call site invokes it **bare**, leaving three merge knobs at defaults
that misbehave precisely when a **package/directory rename** lands
between `main` and a `release/*` branch — producing spurious conflicts
on backports that would otherwise apply cleanly.

This PR wraps all backport `cherry-pick` invocations with the same three
settings:

```
git -c merge.renameLimit=999999 \
    -c diff.renameLimit=999999 \
    -c merge.directoryRenames=true \
    cherry-pick -Xrename-threshold=40% ...
```

- **`merge.renameLimit` / `diff.renameLimit`** — Git silently skips
inexact rename detection once the number of unpaired added/deleted paths
exceeds the limit (warning only). A package-wide rename can blow past
the default, degrading renamed files to "deleted + added" so picked
hunks land on paths that no longer exist. Raised so detection stays on.
- **`merge.directoryRenames=true`** — the default `conflict` will not
auto-place a file the backport *adds* under an old package path into the
renamed directory. Backports that add files are common here (see the
feature-absent guard in `create-backport-branch.sh`).
- **`-Xrename-threshold=40%`** — a rename that also rewrites
`package`/`import` lines can drop a small file's similarity below the
50% default and miss the rename.

Applied **identically** at all three cherry-pick call sites so no stage
can disagree with another over a rename:

- `.github/scripts/prepare-backport-checkout.sh` — pre-merge preflight
cherry-pick of the squashed range.
- `.github/scripts/create-backport-branch.sh` — post-merge fallback
cherry-pick that opens the draft backport PR.
- `.github/workflows/direct-backport-push.yml` — post-merge green path
that cherry-picks straight onto the release branch (thanks @xuang7 for
catching this one).

Pure configuration passthrough to the merge machinery — no control-flow
change, no new dependencies.

### Any related issues, documentation, discussions?

Closes #6963

### How was this PR tested?

This is a configuration-only change to two shell scripts and one
workflow's shell step, with no control-flow change. Verified `bash -n`
(syntax) on the edited scripts and YAML parse on the workflow. The added
`-c` flags and `-Xrename-threshold` are standard, long-supported `git
cherry-pick` / merge-machinery options, so behavior on the existing
(no-rename) path is unchanged; the new settings only take effect when a
rename is present, which is exactly the case that previously conflicted.
No unit tests exist for these CI helper scripts, and the real end-to-end
path (backport preflight + Direct Backport Push) exercises them on the
next backport-labeled PR.

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.8)

---------

Co-authored-by: Claude Opus 4.8 (1M context) <no...@anthropic.com>

Report URL: https://github.com/apache/texera/actions/runs/30399782563

With regards,
GitHub Actions via GitBox