docs(assert): add a note about unreliable equality

[tomas-zijdemans]

Ref: #6982 and #6984

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.20%. Comparing base (e80e6bb) to head (adcc8e6).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6989      +/-   ##
==========================================
- Coverage   94.26%   94.20%   -0.06%     
==========================================
  Files         602      613      +11     
  Lines       43662    47710    +4048     
  Branches     7063     8299    +1236     
==========================================
+ Hits        41159    44947    +3788     
- Misses       2447     2696     +249     
- Partials       56       67      +11     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lionel-rowe]

This might be better to word more generically, as there are other objects that could suffer from this problem, and also (as of current logic, pending decision on proposed logic of #6982) only potential false negatives are a known limitation, whereas false positives would be bugs.

I'd word it maybe something like this:

This function is based on value equality, but for some cases (such as data that can only be read asynchronously or function properties) value equality is not possible to determine. In such cases, reference equality is used instead, which may cause false negatives for objects such as Blobs or Requests.

Non-enumerable symbol properties might be the specific implementation detail that makes this problem visible for Blob etc, but it's not the think that makes the problem intractable, so it's probably (?) not worth mentioning.

[tomas-zijdemans]

That is better indeed. Updated now. Thanks @lionel-rowe!

[kt3k]

Looks nicer and clearer! Thanks