Add patch to fix proj_trans_bounds()

[xylar]

See:
OSGeo/PROJ#4526
conda-forge/pyproj-feedstock#160 (comment)

This merge also organizes the other 2 patches for clarity

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[xylar]

@snowman2, please take a look.

[xylar]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/16884438031. Examine the logs at this URL for more detail.}

[snowman2]

Much appreciated. Didn't dig into the details, but approve of the concept.

[xylar]

@snowman2, no worries. I just wanted to make sure this was what you had in mind (in broad strokes). Let's see how it goes in pyproj...

[jjimenezshaw]

Is that normal to have in conda "patched" releases? A user using conda will have a different behaviour than one using the exact release.

[xylar]

We're planning to considering mark the other 2 builds as broken. But, yes, if we can't use this version of proj in pyproj, it's not unusual to patch if the alternative is to just skip the release.

[hobu]

Is that normal to have in conda "patched" releases?

Yes, just like it is normal to have patched releases of things in distros like Debian. The intention is to upstream these patches, which appears to be the case for this one, which is simply waiting on a release.

We're planning to mark the other 2 builds as broken.

IMO, it's a bit much to go back and x these builds out for this issue.

[xylar]

IMO, it's a bit much to go back and x these builds out for this issue.

@hobu, Yeah, I hope you're right. I'll only do it if it seems like downstream packages (notably pyproj) are picking up the older builds for some reason.