TRPCError code mismatch when client and server share AppRouter type but handle NOT_FOUND differently

Error code propagation inconsistency

When a server procedure throws a TRPCError with code NOT_FOUND, the client receives an error object whose shape reflects the mapped HTTP status. However, the inferred type from the shared AppRouter does not appear to constrain the possible error codes per procedure, allowing the client to handle only a subset of codes at compile time while the server may throw additional codes at runtime.

Constraints

• Both client and server import the same AppRouter type definition.
• Server uses throw new TRPCError({ code: 'NOT_FOUND' }) in a procedure.
• Client catches errors via try/catch around the typed procedure call.
• No custom error formatter or middleware alters the error shape.

Questions

1. Does the current type inference guarantee that every TRPCError code thrown by a procedure is represented in the client-side error union for that procedure?
2. If the guarantee is absent, what is the recommended pattern to exhaustively handle server-thrown error codes without duplicating code lists?