feat: define what a nil filter value means across storage adapters

[Lutherwaves]

#247 settled that a nil filter value means IS NULL, and #251 makes that work on SQL. The other adapters read {"deleted_at": nil} differently:

Adapter	Result
SQL, Memory	deleted_at IS NULL (#251)
CosmosDB	c.deleted_at = null (L787), which misses documents without the property
DynamoDB List	deleted_at=? bound to NULL (L361), not IS MISSING
DynamoDB Get	the filter is marshalled as the key (L150)

That breaks the "swap the adapter, keep your handlers" promise, and none of it is documented: docs/storage.md only says "exact equalities".

Proposal: nil matches a value that is NULL or absent.

• SQL / Memory (fix(storage/sql): skip empty bindings maps on nil-only filters #251)
• CosmosDB: (NOT IS_DEFINED(c.x) OR IS_NULL(c.x))
• DynamoDB List: (x IS MISSING OR x IS NULL)
• DynamoDB Get: return an error for nil key values
• Document it in docs/storage.md and the StorageAdapter godoc
• One contract test run against every adapter

Related: #200 (Count returns 0, nil on DynamoDB and Cosmos).