assert: prevent OOM when generating diff for large objects

[AbdelrahmanHafez]

Fixes #61346

Solution

Add a 2MB limit to inspectValue() output in assertion_error.js. When truncation occurs:

• A ... [truncated] marker is added to the output
• The error message indicates lines were skipped

The assertion logic is unaffected; only the error output is truncated.

Trade-offs

If both objects produce very large inspect output and happen to match exactly in the first 2MB but differ later, the diff would appear identical. However:

• The alternative is an OOM crash, which is worse
• The assertion result is still correct (=== failed)
• A truncation marker indicates output was cut off
• Users can examine error.actual and error.expected programmatically

Alternative approaches considered

1. Skip diff entirely for huge objects - Just show "Objects are not equal (output too large to diff)"
2. Smarter truncation - Find where objects differ first, truncate around that area. However, this is complex and the performance benefit is unclear: for objects with exponential paths, even traversing them could be expensive, and the subtree around the difference may still contain references to shared objects.

[AbdelrahmanHafez]

@avivkeller
Could you approve the CI run to verify if something's broken? I'd like to fix any potential issues tonight if possible.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/70780/

[AbdelrahmanHafez]

I've investigated the CI failures:

GitHub Actions failures (coverage-linux, test-linux, test-tarball-linux, x86_64-linux): All terminated with exit code 143 due to runner shutdown signals, not test failures. The tests that completed before shutdown all passed.

##[error]The runner has received a shutdown signal.
##[error]Process completed with exit code 143.

Jenkins CI failures (node-test-commit-linuxone, node-test-commit-plinux, node-test-linux-linked-*): These show "tests failed" but I cannot access the logs to verify if they're related to this PR or infrastructure issues.

Could a maintainer please re-trigger CI or check the Jenkins logs? @avivkeller