Bring master's README in line with develop's

[thc1006]

Reopening #1113 against master, which is the only branch it applies to. Retargeting it to develop left nothing to apply, and I did not say why clearly enough at the time.

Ruff (format) fails on master right now, and any pull request into master shows a red lint (3.10) for a reason that has nothing to do with it. Checked against both branches with the ruff CI installs:

master   9bd6ad3a   1 file would be reformatted, 297 files already formatted   (README.md)
develop             307 files already formatted

develop's README is already formatted this way. The diff between the two READMEs is exactly this change, which is why moving the pull request across made it a no-op.

So this takes develop's file rather than running the formatter again. The result is byte for byte identical to develop, which means the next release sync has nothing to reconcile here instead of carrying a conflict.

Whitespace and quotes only: single quotes in one call, a call split across three lines that fits on one, and two blocks indented two spaces rather than four. No snippet behaves differently when run.

Why it drifted. The linters job installs ruff unpinned, and recent versions format Python code blocks inside Markdown. That will happen again on whatever the formatter widens to next, on a branch that was green and without a commit to explain it. Pinning ruff in linters.yml is the durable fix and is its own change; happy to send it if you want it.

One thing to expect: this pull request will show a single check. The paths filters mean a README-only change runs the docs build and nothing else, so the linters job that would confirm the fix does not run on the change that makes it. It runs on the next thing to touch master, which is #1112.

[Gui-FernandesBR]

Sorry @thc1006 but we cannot accept this PR since it is targeting to master branch. If develop is correct, we should wait until the next release to update the master branch

[thc1006]

Understood, and that rule makes sense of a few things I had been reading as problems.

I had taken the red on master as something to fix. In your model it is master being a snapshot that has not been synced yet, which is a different thing entirely and not mine to route around. develop already has this exact README, so the next release sync carries it over on its own.

It also explains why #1105 and #1112 kept moving to develop. I had read that as a disagreement about where pull_request_target reads its workflow from; it was the branch rule, and the answer to my timing question on #1112 is that the wait is the intended cost.

Nothing outstanding here from me.