Original text:
RESET_STREAM frame (frame-reset-stream) with an appropriate error code to terminate just the affected stream. <del> RESET_STREAM MUST be instigated by the protocol using QUIC. RESET_STREAM carries an application error code.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </del>  automatic RESET_STREAM. <del> Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. </del> Application protocols SHOULD define rules for handling streams that are prematurely cancelled by either endpoint.

Reviewer comments:
This cribs Lucas' proposed tweak and makes a few other tiny adjustments.
The transport currently says It feels more correct to say I'll prepare a PR if my understanding and suggestion is correct.
It's a subtle point, but it seems OK. I do find the use of a possessive in that phrasing abhorrent though.
I made a stupid typo, whoops. Open to alternative phrasing. "Pulling the rug" comes to mind...
You're changing the meaning here, and I think the existing phrasing is correct. If you don't understand the application protocol, you don't know which streams are safe to reset and which will be connection-fatal. Telling the application protocol that you reset the stream doesn't make it any less fatal if you reset the wrong stream.
So looking at the paragraph in entirety I agree with NAME : directly or through the receipt of a STOPSENDING frame from a peer. RESETSTREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints. Is the intention to describe why " RESET_STREAM MUST be instigated by the protocol"? The words following the normative text are a bit wooly/weasely. I think this paragraph slightly falls victim to the problem that you raised on URL but from the other side of the coin. Nowhere else do we use the phrase "protocol using QUIC" - it sounds a bit bcp56(bis).
Yes -- QUIC doesn't unilaterally reset streams, because it doesn't have the context to do so safely. The application layer on one of the peers has to do that, even if it does so via a STOP_SENDING transmitted by QUIC.
Small commentslgtm

Revised text:
RESET_STREAM frame (frame-reset-stream) with an appropriate error code to terminate just the affected stream.  <ins> Resetting a stream without the involvement of the application protocol could cause the application protocol to enter an unrecoverable state.  RESET_STREAM MUST only be instigated by the application protocol that uses QUIC. RESET_STREAM carries an application error code, for which the semantics are defined by the application protocol.  Only the application protocol is able to cause a stream to be terminated.  A local instance of the application protocol uses a direct API call and a remote instance uses the STOP_SENDING frame, which triggers an </ins> automatic RESET_STREAM.  Application protocols SHOULD define rules for handling streams that are prematurely cancelled by either endpoint.