[CI] Read re-enabled issues with git log, not git cherry (#194485)

The *Check for keep-going label and re-enabled test issues* step intermittently stalls for tens of minutes.
- [Example run, release branches are the worst-affected cohort](https://github.com/pytorch/pytorch/actions/runs/32523305318/job/96933135846)

It is not confined to release branches. Healthy p50 is ~0.5–2 min depending on cohort, but 19.2% of `pull` invocations exceed 10 minutes, additionally observed ghstack also heavily hit, with 1/4 of jobs 10+ minutes. The step then fails open: the exception is swallowed and `reenabled-issues` returns empty. The stall produces no result.

get_reenabled_issues scrapes commit subjects for "Fixes #NNNNN". It used `git cherry -v origin/main`, which computes patch-ids and so needs the trees of every commit off main. CI checks out treeless (--filter=tree:0), so each of those is lazily fetched from the promisor remote one round trip at a time -- observed stalling this step for 102 minutes before erroring and discarding the result anyway.

`git log --format=%s` reads commit objects only, which the clone always has. This is behavior-preserving, not just faster: git cherry -v prints subject lines, and prints both "+" and "-" entries, so the commits reaching the regex are exactly origin/main..HEAD. The patch-id work only selects the prefix character, which REENABLE_TEST_REGEX never reads. %B was rejected -- feeding commit bodies to the regex is a behavior change, not a fix.

Git command output test:
```
# git log --format=%s <upstream>..HEAD feeds the re-enable regex the same text
# git cherry -v <upstream> did -- including commits whose patch is already
# upstream, which is what people assume git cherry filters out.
rm -rf /tmp/rB && git init -q /tmp/rB && cd /tmp/rB

# upstream = stand-in for origin/main; the "PR" line is built on the default branch
echo a > f && git add f && git commit -qm "base" && git branch upstream
echo b > f && git add f && git commit -qm "Fixes #12345" && git branch feat

# upstream moves on, then the same patch lands there: same patch-id, new sha, so
# feat's commit is still inside upstream..feat
git checkout -q upstream && echo z > g && git add g && git commit -qm "upstream moved on"
git cherry-pick feat >/dev/null

echo "OLD: git cherry -v upstream feat"; git cherry -v upstream feat
echo "NEW: git log --format=%s upstream..feat"; git log --format=%s upstream..feat

# "-" = patch already upstream, printed anyway. Same commit set both ways; the
# patch-id work only picks the +/- prefix, which the regex never reads.
```

Authored with assistance from Claude.
Pull Request resolved: https://github.com/pytorch/pytorch/pull/194485
Approved by: https://github.com/pytorchgreenlight, https://github.com/jathu, https://github.com/atalman, https://github.com/huydhn