sl pull mistakes an issue number for the pull-request number

When a GitHub squash commit title contains both an issue reference and the appended pull-request number, Sapling selects the issue number as the pull request.

Example commit:

https://github.com/omry/omegaconf/commit/93023e78016f16e68dacaebf0d35a5eebff727e5

Its title is:

Preserve ValueNode types in OmegaConf.masked_copy (#813) (#1308)

#813 is an issue. The actual pull request is #1308:

https://github.com/omry/omegaconf/pull/1308

Running:

$ sl pull
pulling from ssh://[email protected]/omry/omegaconf.git
warning: failed to read from Github for landed commits (RuntimeError('{
 "data": {
  "repository": {
   "pullRequest": null
  }
 },
 "errors": [
  {
   "type": "NOT_FOUND",
   "path": ["repository", "pullRequest"],
   "message": "Could not resolve to a PullRequest with the number of 813."
  }
 ]
}')), not marking commits as landed

The pull succeeds, but Sapling does not mark the corresponding local commits as landed.

Expected behavior:

sl pull should identify #1308 as the associated pull request and correctly mark the corresponding commits as landed.

Environment:

Sapling 0.2.20260317-201835+0234c21f

Related reports with the same top-level warning but different causes:

• https://github.com/facebook/sapling/issues/1215
• https://github.com/facebook/sapling/issues/583