Change:
From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. <del> WebTransport over HTTP/3 does not support 0-RTT. </del> <ins> Clients cannot initiate WebTransport in 0-RTT packets, as the CONNECT method is not considered safe; see Section 10.9 of HTTP3.  However, WebTransport-related SETTINGS parameters may be retained from the previous session as described in Section 7.2.4.2 of HTTP3.  If the server accepts 0-RTT, the server MUST NOT reduce the limit of maximum open WebTransport sessions from the one negotiated during the previous session; such change would be deemed incompatible, and MUST result in a H3_SETTINGS_ERROR connection error. </ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM.

Discussion:
There is this sentence about 0-RTT: I think this needs a better explanation. I expect that CONNECT requests can be sent during 0-RTT period, but WebTranpsort streams cannot be open before response to the CONNECT requests is received. Clients may remember that WebTransport was supported by a server and may try to negotiate sessions during 0-RTT.
CONNECT is considered by HTTP semantics, so the current specs state that it be sent in 0-RTT. We could override those however and explicitly state that 0-RTT is allowed for this specific kind of CONNECT request, but I'm not sure we should? If a server implementation makes creation of a WebTransport session expensive, then this could be used as a DoS vector. That said, servers could protect themselves by either disabling 0-RTT on that origin, or by returning 425 if their intermediaries support the Early-Data header. All this to say: here there be dragons, and if we want to add this feature we'll need to write guidance for implementors.
The MUST NOT only applies in absence of other indications; an API flag could be such indication. That said, I am not sure it's worth investing into designing WebTransport 0-RTT support at this point.
I agree we do not need to allow 0RTT for WebTransport. Since WebTransport does not support 0RTT what will happen to the SETTINGSENABLEWEBTRANSPORT setting when 0RTT is used on a HTTP/3 connection and in the previous session WebTransport support was negotiated? There is some explanation in the HTTP/3 draft: SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. In the WebTransport case 0RTT data is not relevant, but there may be a small window when a client has 1RTT keys but still do not have the settings from a server. We can allow the client to remember WebTransport setting or WebTransport setting needs to be negotiated in each session therefore the client must wait for the settings from the server before confirming that WebTransport is supported. I am fine with either way, but I think the WebTransport draft needs a couple of sentences to explain the behavior.

HTTP/3 draft says: This obviously only works for SETTINGSENABLEWEBTRANSPORT if the server is not allowed to go from 1 to 0 while accepting 0-RTT; we should probably clarify this explicitly.