Fix false positive reportUnnecessaryComparison for bytes vs bytearray

[behlole]

Fixes #11433.

Context

isTypeComparable in typeEvaluator.ts has an early return false for the "both operands are disjoint built-in classes" case. That branch already special-cases bool / int (because bool literal values can collide with 0 / 1), but bytes and bytearray fall through unhandled, even though their __eq__ implementations cross-compare by content. This produces a false-positive reportUnnecessaryComparison for very common code such as:

data = bytearray(4)
if data == b"\x00\x00\x00\x00":
    ...

Change

Add a bytes / bytearray comparable case in isTypeComparable parallel to the existing bool / int handling. If both operands are bytes-like built-ins, treat them as comparable. The Literal[bytes] form in the issue is handled by the same code path because a Literal[bytes] value is still a bytes instance (ClassType.isBuiltIn(t, 'bytes') is true for it).

Test plan

New sample packages/pyright-internal/src/tests/samples/comparison3.py covers:

• bytes ↔ bytearray in both directions, with == and != — must NOT emit the diagnostic (validates the new branch).
• bytearray ↔ Literal[bytes] — must NOT emit (validates the literal form from the issue).
• bytes ↔ str — must still emit (regression guard: the new branch must not over-relax).

Comparison3 test in typeEvaluator6.test.ts runs the sample twice (default rule set off, then with reportUnnecessaryComparison = 'error') and asserts the expected diagnostic count (0, then 1).

Notes

Considered also adding memoryview to the bytes-like set, since memoryview(b"a") == b"a" is also True at runtime, but kept it out of this PR to match the issue's scope exactly. Happy to add it in a follow-up if maintainers prefer.

[behlole]

@microsoft-github-policy-service agree

[rchiodo]

Approved via Review Center.