[rr-]

In ReST, a line that starts with a role was read as a field named after the role. So in

Called after the request is dispatched.

This calls all functions decorated with
:meth:`teardown_request`, and :meth:`Blueprint.teardown_request`
if a blueprint handled the request.

the second paragraph lost its second and third lines to a DocstringMeta with key meth and a description starting `teardown_request`,, and compose wrote it back as :meth: `teardown_request`, ... after the description.

This reads a field's name the way docutils does: a colon inside the name is followed by neither whitespace nor a backtick, and the colon closing it is followed by whitespace or the end of the line. Any other line starting with a colon is text. It continues the field before it, or the description if no field came yet, and after a blank line it ends the field list and goes to the long description. The example above now parses with the whole paragraph in the long description and no meta.

One more case follows from the same rule: :param x:desc, with no space after the closing colon, is no field in docutils and is now text too. A line starting with a colon that holds no other colon, such as :param x, is still a field that cannot be read and reports bad-field, as before.

Parity against origin/main: 85 of 29,143 docstrings differ, 78 from the case files (corpus docstrings from flask, requests, sphinx, google-auth, scipy and numpy, plus the four new rest/roles_* cases) and 7 from the stdlib, none generated. Every one has a line starting with a role, and each differs in parse REST and its composes, and in parse AUTO and its composes where auto picked ReST. In one numpy docstring auto-detection now picks Numpydoc, because ReST no longer finds fake role fields in it. No case or stdlib docstring writes :name:text without a space.

Bench (just bench): parse rest 91.2 ms on main vs 92.3 ms (1.01x), parse auto 341.7 ms vs 345.2 ms (1.00x), and the other workloads 0.95x to 1.01x.