feat: implement storage Count() or return an error instead of (0, nil)

[Lutherwaves]

Check Existing Issues

• I have searched the existing issues and discussions.

Problem Description

The Count operation on the DynamoDB and CosmosDB storage adapters is a stub that silently returns 0, nil. Callers cannot distinguish "there are zero rows" from "counting isn't implemented", which leads to silent data-correctness bugs (e.g. pagination/empty-state logic that trusts the count).

storage/dynamodb.go:313:

func (s *DynamoDBAdapter) CountContext(ctx context.Context, dest any, filter map[string]any, params ...map[string]any) (int64, error) {
	// TODO Implement
	var total int64
	return total, nil
}

storage/cosmosdb.go:494:

func (s *CosmosDBAdapter) CountContext(ctx context.Context, dest any, filter map[string]any, params ...map[string]any) (int64, error) {
	// TODO Implement
	var total int64
	return total, nil
}

There's also an inconsistency in how unimplemented methods fail across adapters: storage/sql.go:421 (QueryContext) returns an explicit "not implemented yet" error, while these Count stubs return a fake zero. The two stubbing strategies should be reconciled.

Desired Solution you'd like

Pick one consistent strategy for not-yet-implemented adapter methods, and apply it:

• Preferred: implement Count for both adapters (DynamoDB SELECT COUNT(*) via PartiQL / Select: COUNT; Cosmos SELECT VALUE COUNT(1)), honoring the same filter semantics as List.
• Minimum: return a sentinel error (e.g. a shared ErrNotImplemented) instead of 0, nil, matching how SQLAdapter.QueryContext already behaves, so callers fail loudly.

Additional Context

Found during a general audit of the library. A failing zero is the worst of both worlds; even the minimum fix (explicit error) removes a real silent-corruption foot-gun.