`panic: tls: setPskToUConn failed: only binders are allowed to change on state 'PskAllSet'` — low reproducibility, but panic crashes program

[gospider001]

Description:
While using utls v1.8.0 for TLS 1.3 connections, my program occasionally panics with:

panic: tls: setPskToUConn failed: only binders are allowed to change on state `PskAllSet`
goroutine 79898 [running]:
github.com/refraction-networking/utls.uAssert(...)
    /Users/zhaoxiaoxiao/go/pkg/mod/github.com/refraction-networking/utls@v1.8.0/u_common.go:801
github.com/refraction-networking/utls.(*sessionController).setPskToUConn(0xc00dd6e180)
    /Users/zhaoxiaoxiao/go/pkg/mod/github.com/refraction-networking/utls@v1.8.0/u_session_controller.go:206 +0x28e
github.com/refraction-networking/utls.(*UConn).uApplyPatch(0xc001819208)
    /Users/zhaoxiaoxiao/go/pkg/mod/github.com/refraction-networking/utls@v1.8.0/u_conn.go:198 +0x55
...

---

Details:

• This issue is hard to reproduce. It only happens occasionally when connecting to some servers (possibly after handshake, when the server sends NewSessionTicket or other TLS 1.3 post-handshake messages).
• I am not fully sure if this is a bug in uTLS, but the strict assertion causes a panic, which crashes the entire program.
• Even if this behavior is correct per uTLS’s design, it would be helpful if this situation returned an error instead of panicking, so that applications can recover gracefully.

---

Steps to Reproduce:

• Set up a TLS 1.3 connection using utls.UConn
• Connect to a real-world server (e.g., CDN provider)
• Rarely, the panic occurs while reading from the connection after handshake

Reproduction rate: low, ~<0.001% connections (hard to create a minimal reproducer).

Expected Behavior:

• Instead of panic, return an error or allow the application to handle unexpected PSK/session changes gracefully.
• Applications that use uTLS in production should not crash on rare protocol edge cases.

---

Environment:

• uTLS version: v1.8.0
• Go version: go1.25
• OS: macOS/Linux
• TLS version: TLS 1.3

---