fix(xgplayer-streaming-shared): detect range response mismatch regardless of rangeRequestMustReturn206

[raphyabak]

Summary

Fixes #1941.

_getRangeResponseMismatchReason() in both FetchLoader and XhrLoader returned early unless rangeRequestMustReturn206 was enabled:

_getRangeResponseMismatchReason (response) {
  if (!this._rangeRequestMustReturn206) return false
  return getRangeResponseMismatchReason(...)
}

That option only controls whether a non-206 response is permitted — it has no bearing on whether a 206 response's declared Content-Range/Content-Length actually matches the bytes that were requested. With rangeRequestMustReturn206 left at its default (false), a server or intermediary returning a 206 for the wrong byte range was accepted silently, letting mismatched segment data reach the media parser instead of surfacing as a network error.

This is already covered by existing regression tests in both fetch.spec.js and xhr.spec.js ("rejects range request when content-range and content-length do not match request range"), which currently fail against main.

Fix

• Run the mismatch check unconditionally in both loaders.
• FetchLoader's error message now reflects the specific mismatch reason (start/end/content-length), matching what XhrLoader already did and what the existing tests expect ('bad response,' + reason rather than the generic 206 message for every case).

Test plan

• The two existing regression tests referenced above (fetch.spec.js, xhr.spec.js) now pass; they were failing on main before this change.
• Verified the regression: reverting the source change reproduces the exact test failures reported in the issue.
• Full package suite: npx jest packages/xgplayer-streaming-shared --runInBand — 8 passing.
• biome check passes on the changed lines (kept the diff scoped to the two logic lines per docs/ai-harness/quality-gates.md's "keep lint and format scope narrow" guidance, rather than letting the formatter rewrite the whole file).