Fix libtorch-extract being skipped on nightly-branch pushes (#194610)

Fixes libtorch nightly binaries not being built or published on nightly-branch pushes.

## What

`libtorch-extract` is the only job in `linux_binary_build_workflow.yml.j2` that does not use the shared `owner_if` guard. It hardcodes a bare owner check:

```yaml
libtorch-extract:
  if: ${{ github.repository_owner == 'pytorch' }}
  needs: [manywheel-build]
```

The eight sibling jobs all use `!{{ owner_if }}`, which expands to `!failure() && !cancelled() && github.repository_owner == 'pytorch'`. This gives `libtorch-extract` the same guard and regenerates.

## Why

On a push to the `nightly` branch:

1. `get-docker-tag` is skipped **by design** — `if: … && github.ref_type == 'tag'`. Its own comment notes that on branch runs its outputs read blank and the floating Docker Hub tag is used.
2. `manywheel-build` survives that skipped dependency, because a status function in its `if` opts it out of the default "all `needs` must succeed" rule. It runs and succeeds.
3. `libtorch-extract` has no status function in its `if`, so the skip propagates into it and it never runs.
4. No extract means no artifact, so all seven `libtorch-*-upload` jobs fail at `Artifact not found`.

Observed in [run 32703333819](https://github.com/pytorch/pytorch/actions/runs/32703333819) (2026-08-24 nightly): `libtorch-extract` was marked **skipped at 11:46:48** — six seconds before the uploads started, and far too early for `manywheel-build` to have completed, which is the tell that it was skipped by graph evaluation rather than by anything it did. All 7 libtorch uploads then failed:

```
##[error]Unable to download artifact(s):
Artifact not found for name: libtorch-cuda13_2-shared-with-deps-release
```

This is not a new break. Until the recent `continue-on-error` change in `_binary-upload.yml`, the download failure was swallowed and "Upload binaries" reported success having uploaded nothing — so libtorch nightlies had silently not been publishing on branch pushes. That change didn't cause this; it made it visible.

## Test plan

- Regenerated with `.github/regenerate.sh`; the only generated change is the single `if:` line in `generated-linux-binary-manywheel-nightly.yml` (it is the only workflow with `libtorch_extraction_configs`).
- Re-running the generator produces no further diff, so the checked-in file is in sync.
- `yaml.safe_load` on the regenerated workflow parses; 24 jobs; `libtorch-extract.if` is now `${{ !failure() && !cancelled() && github.repository_owner == 'pytorch' }}`.

Note this cannot be meaningfully validated by `workflow_dispatch`: on a manual run `github.ref_type` is `branch`, so `get-docker-tag` skips the same way, and `event_name != 'push'` makes `continue-on-error` evaluate true, so the uploads would go green without uploading anything. A `ciflow/binaries_libtorch/*` tag exercises the full chain, and the next nightly is the real confirmation.

## Follow-up (deliberately not in this PR)

`libtorch-upload` uses `owner_if`, which tolerates a **skipped** dependency — that is why seven uploads ran against a missing artifact rather than being skipped themselves. Adding `needs.libtorch-extract.result == 'success'` would collapse seven confusing red uploads into one signal at the real failure point. Kept separate so this minimal fix can land quickly and restore the artifacts.

Pull Request resolved: https://github.com/pytorch/pytorch/pull/194610
Approved by: https://github.com/pytorchgreenlight, https://github.com/georgehong