test: add deepStrictEqual tests for better accuracy

[lumirlumir]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

Hello,

In this PR, I've added several test assertions in tests/languages/json-source-code.test.js to use assert.deepStrictEqual.

This change ensures that complex objects are compared by their deep structure rather than just by reference, improving the reliability of the tests.

These test cases help prevent unintended changes to deeply nested properties.

What changes did you make? (Give an overview)

Related Issues

Is there anything you'd like reviewers to focus on?

[lumirlumir]

@mdjermanovic Thanks for your guidance — it gave me a good opportunity to think more carefully about deep vs. shallow equality.

I've added a commit that addresses your comment, and this change doesn't affect the existing behavior.

[lumirlumir]

For more context on this change:

Without the deepStrictEqual test, we can't verify whether the ast has changed due to unintended side effects.

For example, the previous test case "should create a JSONSourceCode instance" wouldn’t catch the issue shown below because they don't inspect nested properties. (This is a simplified example to illustrate the point — real-world cases might differ slightly.)

	/**
	 * Creates a new instance.
	 * @param {Object} options The options for the instance.
	 * @param {string} options.text The source code text.
	 * @param {DocumentNode} options.ast The root AST node.
	 */
	constructor({ text, ast }) {
		super({ text, ast });
		this.ast = ast;
+		this.ast.loc = {start: {line: 1, column: 1, offset: 0}, end: {line: 1, column: 2, offset: 1}};
		this.comments = ast.tokens
			? ast.tokens.filter(token => token.type.endsWith("Comment"))
			: [];
	}

[nzakas]

I'm not sure I see the value in these changes. Fundamentally, these tests are not interested in whether or not the data structure has changed, they only care that an expected value is returned and that the value is === to the stored value. It seems beyond the scope of the tests to care whether the object has been mutated in some way. I'm not sure that's a guarantee we need (or want) to make.

The example given (mutating the AST inside the JSONSourceCode constructor) isn't a situation we're concerned with because we are in 100% control of it. If we need to mutate the AST in some way, that's okay, because rules don't receive the AST until after JSONSourceCode is instantiated.