feat(NODE-4793): add Symbol.toStringTag to all BSON types

[sarthaksoni25]

Description

Summary of Changes

Adds Symbol.toStringTag to all BSON types by implementing the getter in the BSONValue base class, delegating to this._bsontype. Since _bsontype is abstract on BSONValue and implemented by every subclass, all 13 BSON types inherit the correct tag automatically.

Before:
Object.prototype.toString.call(new ObjectId()) // '[object Object]'

After:
Object.prototype.toString.call(new ObjectId()) // '[object ObjectId]'

Notes for Reviewers

Follows the same pattern as the existing bsonType symbol getter added in NODE-7255. The implementation is a single getter on BSONValue — no changes needed in individual subclasses.

Double check the following

• Lint is passing (npm run check:lint)
• Self-review completed
• PR title follows the correct format: feat(NODE-4793): add Symbol.toStringTag to all BSON types
• Changes are covered by tests (14 new tests added in bson_type_classes.test.ts)
• No new TODOs

[tadjik1]

Approach is right - matches the existing bsonType getter pattern on BSONValue. One suggestion: override Symbol.toStringTag on UUID to return 'UUID'. _bsontype is a wire-protocol key and must stay 'Binary' (serializer dispatches on it), but Symbol.toStringTag is a developer-facing identity hint with no wire impact - making it reflect the JS class gives nicer debug output ([object UUID]) without breaking anything. The test would then assert toStringTag === TypeClass.name uniformly across all types.

[nbbeeken]

> Object.prototype.toString.call(Buffer.alloc(0))
'[object Uint8Array]'

It is not always the case that the string tag matches the class name, because UUID is a trivial subclass of Binary and Binary is the relevant BSON type it may make sense to keep these matching the _bsontype field. It also is not only a developer hint here's an example where it's a load bearing type check.

An additional benefit to adding this field is it adds the same functionality we added when we introduced the @@mdb.bson.type symbol but without the need to import/create something from the library.

Just my opinion here :) not strongly held

[tadjik1]

hi @sarthaksoni25, thanks for you work, everything looks correct, simple and clean implementation, well done!
I left one suggestion, please let me know what you think.

[addaleax]

Should this be considered semver-major?

[tadjik1]

hi @sarthaksoni25, after discussing this change with the team we have decided against it. the main reason is that it can break existing functionality of external packages that might rely on the string representation of BSON instances. and potential benefits do not justify complexity of the migration.
Once again, thanks a lot for your contribution!