fix: cover the BSON types the mongo span hook dropped

[aradng]

response_hook serializes every command reply into a span attribute, but _parse_mongo_types was missing several BSON types. Each miss raises inside the listener — pymongo swallows that, so queries are unaffected, but the span loses db.mongodb.server_reply and a traceback is logged.

I enumerated every BSON type against orjson to find the real gaps rather than fixing only the one that surfaced:

type	before	now
RawBSONDocument	✗ raised	dict(obj)
decimal.Decimal	✗ raised	str(obj)
Regex	✗ raised	{"$regex", "$options"}
MinKey / MaxKey	✗ raised	{"$minKey": 1} / {"$maxKey": 1}
Code, Int64, datetime, UUID	orjson native	unchanged

RawBSONDocument

What write replies actually arrive as. On services/ai staging this was 284 lines in 25 minutes, one per upsert — every failing payload carried updatedExisting. The first test reproduces it byte-for-byte:

RawBSONDocument(b'\x1e\x00\x00\x00\x10n\x00\x01\x00\x00\x00\x08updatedExisting\x00\x01\x00')

Decimal — a regression from #32

#32 registered a Decimal128 → Decimal decoder on the client, so replies echoing a stored decimal now surface as decimal.Decimal, which orjson cannot serialize and this hook had no branch for. Reproduced against a real Mongo: insert Decimal128, find_one, then serialize the captured reply — Type is not JSON serializable: decimal.Decimal. It passes now, with the same 5 replies checked and zero failures.

Anything on 0.5.2 storing decimals is affected — bluprint/finance most of all, where PydanticDecimal128 is used across wallets, invoices and commissions.

Dispatch table

Adding four branches pushed the if-chain past ruff's complexity limit (14 > 10), so it is a table now. Order is preserved where it matters: Binary precedes bytes, which it subclasses.

0.5.2 → 0.5.4, 111 tests pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Tyg1MP35Bn36f9nyBfsfei