fix(tracing): mark database query/mutation spans as client, not internal

[eeshsaxena]

Fixes #10868.

Problem

Spans for database queries and mutations are created with SpanKind SKInternal ("internal"), but per the OTel database span semantic conventions a database call is a client span. Because of the wrong kind, exporters that map OTel span kinds to their own types (e.g. Datadog) classify these as custom rather than a DB span, which breaks OTel-trace → DB-monitoring correlation.

The DataConnector backend already gets this right — it uses SKClient for both its query and mutation spans — so Postgres and MSSQL are simply out of line with it.

Fix

Change the newSpan ... SKInternal to SKClient for the DB query/mutation spans in both backends, matching DataConnector and the semantic conventions.

The issue only mentions the Postgres query span, but the same defect is present on every sibling DB span, so all of them are corrected together:

• Backends/Postgres/Instances/Transport.hs — Postgres Query for root field ... and both Postgres Mutation for root field ... spans.
• Backends/MSSQL/Instances/Transport.hs — MSSQL Query for root field ... and MSSQL Mutation for root field ... spans.

These are the only SKInternal uses in the two transport modules, and each is a database span; no non-DB internal spans are affected. SKClient renders as "client" (see Tracing.TraceId).