fix(expect): Ensure we can always self toEqual

[dubzzz]

Description

This Pull Request proposes a fix for the issue #8081. It fixes a typing issue making expect(self).toEqual(self) unable to compile for some types.

Example:

function expectMany<T>(value: { enabled: false } | { enable: true; data: T }) {
  // In Vitest 3.2:
  //
  // Argument of type '{ enabled: false; } | { enable: true; data: T; }' is not assignable to parameter of type '{ enabled: false | AsymmetricMatcher<unknown, MatcherState>; } | { enable: true | AsymmetricMatcher<unknown, MatcherState>; data: AsymmetricMatcher<...> | DeeplyAllowMatchers<...>; }'.
  //   Type '{ enable: true; data: T; }' is not assignable to type '{ enabled: false | AsymmetricMatcher<unknown, MatcherState>; } | { enable: true | AsymmetricMatcher<unknown, MatcherState>; data: AsymmetricMatcher<...> | DeeplyAllowMatchers<...>; }'.
  //     Type '{ enable: true; data: T; }' is not assignable to type '{ enable: true | AsymmetricMatcher<unknown, MatcherState>; data: AsymmetricMatcher<unknown, MatcherState> | DeeplyAllowMatchers<T>; }'.
  //       Types of property 'data' are incompatible.
  //         Type 'T' is not assignable to type 'AsymmetricMatcher<unknown, MatcherState> | DeeplyAllowMatchers<T>'.
  //           Type 'T' is not assignable to type 'AsymmetricMatcher<unknown, MatcherState>'.ts(2345)
  expect(value).toEqual(value);
}

Fixes #8081

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.