ref(feedback): Remove almost duplicate sendFeedback rejection message

[mydea]

Noticed this by chance, this is a redundant message (we also use this as general fallback anyhow).

The two messages have been:

Unable to send Feedback. This is because of network issues, or because you are using an ad-blocker.
Unable to send Feedback. This could be because of network issues, or because you are using an ad-blocker

Which are virtually identical. We can safe some bytes there IMHO.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	23.76 kB	-	-
@sentry/browser - with treeshaking flags	22.35 kB	-	-
@sentry/browser (incl. Tracing)	39.43 kB	-	-
@sentry/browser (incl. Tracing, Replay)	77.52 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	67.39 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	82.22 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	94.33 kB	-0.02%	-18 B 🔽
@sentry/browser (incl. Feedback)	40.43 kB	-0.05%	-19 B 🔽
@sentry/browser (incl. sendFeedback)	28.43 kB	-0.08%	-20 B 🔽
@sentry/browser (incl. FeedbackAsync)	33.32 kB	-0.06%	-19 B 🔽
@sentry/react	25.5 kB	-	-
@sentry/react (incl. Tracing)	41.4 kB	-	-
@sentry/vue	28.2 kB	-	-
@sentry/vue (incl. Tracing)	41.23 kB	-	-
@sentry/svelte	23.79 kB	-	-
CDN Bundle	25.28 kB	-	-
CDN Bundle (incl. Tracing)	39.3 kB	-	-
CDN Bundle (incl. Tracing, Replay)	75.38 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	80.79 kB	-0.03%	-24 B 🔽
CDN Bundle - uncompressed	73.86 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	116.35 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	230.56 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	243.16 kB	-0.09%	-210 B 🔽
@sentry/nextjs (client)	43.46 kB	-	-
@sentry/sveltekit (client)	39.87 kB	-	-
@sentry/node-core	47.53 kB	+0.01%	+1 B 🔺
@sentry/node	146.19 kB	-	-
@sentry/node - without tracing	91.63 kB	-	-
@sentry/aws-serverless	103.08 kB	-	-

View base workflow run

[Lms24]

Sounds fair to me to remove. Wondering if there was an intention behind the special casing for response.statusCode being 0 but given there's no user-facing difference to the callback, this might just have been an oversight.

[mydea]

Sounds fair to me to remove. Wondering if there was an intention behind the special casing for response.statusCode being 0 but given there's no user-facing difference to the callback, this might just have been an oversight.

Yeah I had the same thought, but this should be an equivalent solution at least I suppose!