Simplify patch README commands following review feedback

[msarahan]

Follow-up tweaks from feedback on #938

Once these are approved, I'll port them to the other versions.

CC @isuruf @h-vetinari

[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.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

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

[h-vetinari]

Not sure if you want to include it, but one thing I use as a sanity check is that I commit the rebased patches (on the feedstock), and the look at the diff-of-diffs with git show -a (by default, patches are dealt as binary due to line ending issues, and so don't show up in the diff; -a shows the diff regardless). For patches that had no conflicts to fix, nothing but the initial hash should change. This also catches instances where people (often myself 🙈) forgot to restore --author or --date correctly

[h-vetinari]

This part makes no sense to me. If we've just generated the patches on top of $new with git format-patch, what possible failure mode are we expecting that would justify this almost-certain-to-be-redundant validation?