…n error

If there is a suspended component or an error during hydration there will almost certainly be many additional hydration mismatch errors because the hydration target does not pair up the server rendered html with an expected slot on the client. To avoid spamming users with warnings there was already logic in place to suppress console warnings if such an occurrence happens. This commit takes another approach to avoid queueing thrown errors.

when suspending this isn't that big of an issue becuase queued errors are discarded becasue the suspense boundary does not complete.

When erroring within a resolved suspense boundary however the root completes and all queued errors are upgraded to recoverable errors and in many cases wihll flood the console. What is worse is the console warnings which offer much more specific guidance on what went wrong (in dev) are suppressed so the user is left with very little actionable information on which to go on and the volume of mismatch errors may distract from identifying the root cause error

The hueristic is as follows

1. always queue the first error during hydration
2. always queue non hydration mismatch errors
2. discard hydration mismatch errors before queueing If there is an already queued error or any type

…not use error properties

…sired now