…angled in the #64093 backport (#67564)

### What problem does this PR solve?

Problem Summary:

Every branch-4.1 PR that touches `thirdparty/` fails `Build Third Party
Libraries (macOS-arm64)` after two to three minutes, inside
`download-thirdparty.sh`, long before anything is compiled:

```
patching file 'src/dwarf/Gfind_proc_info-lsb.c'
2 out of 2 hunks failed--saving rejects to 'src/dwarf/Gfind_proc_info-lsb.c.rej'
##[error]Process completed with exit code 1.
```

| PR | base | `Build Third Party Libraries (macOS-arm64)` |
|---|---|---|
| #67378 | branch-4.1 | fail, 5m18s — these hunks |
| #67356 | branch-4.1 | fail, 3m11s — these hunks |
| #67523 | branch-4.1 | fail, 2m43s — these hunks |
| #67554 | branch-4.1 | fail, 2m43s — these hunks |
| **#67535** — same change as #67523 | **master** | **pass, 2h26m full
build** |

The last row is the point: the same content passes on master and dies in
the patch step on branch-4.1.

**Root cause.**
`thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch` is corrupt
on this branch. It arrived that way in `4439e6f6b46` (the backport of
#64093) and does not match the file master carries (`dc70115a432`) —
even though both branches pin the same libunwind 1.6.2 with the same md5
and run byte-identical patching code in `download-thirdparty.sh`.

In master's copy the blank lines around the change are **context**
lines, each a line holding a single space. In this branch's copy they
are **deletion** lines (`-` with nothing after it), with the hunk
headers renumbered to match that reading (`@@ -46,3 +46,8 @@` instead of
`@@ -47,6 +47,14 @@`, `@@ -805,5 +810,6 @@` instead of `@@ -804,7
+812,10 @@`) and the trailing context dropped. That is what a
trailing-whitespace strip followed by a hand repair leaves behind. The
patch now asks `patch(1)` to delete blank lines that the real source
does not have at those offsets.

**Why only macOS.** GNU patch on the Linux runner recovers from it —
`Hunk #1 succeeded at 12 with fuzz 1` — and the Linux job passes, which
is why this went unnoticed for a week. The macOS runner's `patch`
rejects both hunks and `download-thirdparty.sh` exits 1.

**Fix.** Take master's copy verbatim. One file, nothing else.

### Release note

None

### Check List (For Author)

- Test
    - [ ] Regression test
    - [ ] Unit Test
    - [x] Manual test (add detailed scripts or steps below)

Verified against the pinned tarball (`libunwind-1.6.2.tar.gz`, md5
`f625b6a98ac1976116c71708a73dc44a`) with the same patch implementation
the runner uses (`patch 2.0-12u11-Apple`), on two pristine copies of the
extracted source:

| patch file | exit | result |
|---|---|---|
| this branch's current file | **1** | `2 out of 2 hunks failed` —
byte-identical to the CI message |
| this PR's file | **0** | applies cleanly, no `.rej` |

After applying, the weak declaration and the fork land where
`be/src/common/phdr_cache.cpp` expects them:

```
54:extern int doris_unwind_iterate_phdr (int (*callback) (struct dl_phdr_info *, size_t, void *),
55:                                      void *data, unw_word_t ip) __attribute__ ((weak));
...
815:  if (doris_unwind_iterate_phdr)
816:    ret = doris_unwind_iterate_phdr (dwarf_callback, &cb_data, ip);
817:  else
818:    ret = dl_iterate_phdr (dwarf_callback, &cb_data);
```

This branch does define that symbol
(`be/src/common/phdr_cache.cpp:249`), so the fix restores the intended
behaviour rather than being a no-op. Linux builds were already getting
it via fuzz, so no behaviour changes there.

- Behavior changed:
- [x] No. Linux already applied this patch (with fuzz); this only makes
the macOS thirdparty build stop failing.

- Does this need documentation?
    - [x] No.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01DzUYFcGHQH3bnLGCjpncVj

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>