This PR is a first of many that enriches service source to service overrides. In particalar the PR contains:
- introduction of `instrumentation.ServiceNameWithSource` method to be used by all integrations
- 4 integrations covered: grpc, gin-gonic, go-redis, database/sql
- inheritence of service source
- coverage of service mapping configuration
- encoding of source in span.Meta

See other similar PRs in dd-trace-java [PR1 - integration services](DataDog/dd-trace-java#10607),  [PR2- client stats](DataDog/dd-trace-java#10653), [PR3 - config cases](DataDog/dd-trace-java#10658),  [PR4 - manual source](DataDog/dd-trace-java#10704)

<img width="1027" height="655" alt="Screenshot 2026-03-10 at 11 48 36" src="https://github.com/user-attachments/assets/a7db0a35-34cd-4541-bf23-1c8d500af032" />



### Reviewer's Checklist
<!--
* Authors can use this list as a reference to ensure that there are no problems
  during the review but the signing off is to be done by the reviewer(s).
-->

- [ ] Changed code has unit tests for its functionality at or near 100% coverage.
- [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag.
- [ ] There is a benchmark for any new code, or changes to existing code.
- [ ] If this interacts with the agent in a new way, a system test has been added.
- [ ] New code is free of linting errors. You can check this by running `make lint` locally.
- [ ] New code doesn't break existing tests. You can check this by running `make test` locally.
- [ ] Add an appropriate team label so this PR gets put in the right place for the release notes.
- [ ] All generated files are up to date. You can check this by running `make generate` locally.
- [ ] Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally.

Unsure? Have a question? Request a review!


Co-authored-by: raphael.gavache <raphael.gavache@datadoghq.com>

## Summary of changes

Add `_dd.svc_src` meta tag to spans to track the source of the service
name. When an integration overrides the default service name (e.g.,
schema V0 without `removeClientServiceNames`), the tag is set to the
integration name (e.g., `"redis"`, `"kafka"`, `"http-client"`). When a
service name mapping is configured via `DD_TRACE_SERVICE_MAPPING`, the
tag is set to `"opt.service_mapping"`. When the default service name is
used, no tag is emitted.

Jira: https://datadoghq.atlassian.net/browse/APMLP-1015
RFC:
https://docs.google.com/document/d/11OnbVYMDK-c5D-_V4QfOvL0Pc0z5oFQFGY3xSI-W7xk/edit?tab=t.0

## Reason for change

.NET equivalent of
[dd-trace-java#10607](DataDog/dd-trace-java#10607).
Service name source attribution lets the backend know which component
set the service name on each span.

## Implementation details

- **Tag constant**: `Tags.ServiceNameSource = "_dd.svc_src"` and
`SpanContext.ServiceNameSource` property.
- **`ServiceNameMetadata`**: Encapsulates resolved service name and
source attribution. Returned by all schema `GetServiceNameMetadata()`
methods and `PerTraceSettings.GetServiceNameMetadata()`.
- **Schema-level source**: `DatabaseSchema`, `MessagingSchema`, and
`ClientSchema` each use a `Resolve` helper that determines the source:
`"opt.service_mapping"` when from `DD_TRACE_SERVICE_MAPPING`, the
integration key when service name ≠ default, or `null` otherwise.
- **`PerTraceSettings.GetServiceNameMetadata()`**: For AdoNet and AWS
integrations that resolve service names dynamically, returns
`"opt.service_mapping"` for mapped names, the integration key for
suffixed names, or `null` for default.
- **Integration callsites**: ~30 files updated to pass
`serviceNameSource`. Server-side integrations using the default service
name are unchanged.

## Test coverage

- **`DatabaseSchemaTests`**, **`MessagingSchemaTests`**,
**`ClientSchemaTests`**: Tests for source attribution.
- **Snapshot files**: 130+ integration test snapshots and 3 smoke test
snapshots updated.

## Follow-up items

- V1 schema with `DD_TRACE_SERVICE_MAPPING` could emit
`opt.service_mapping` (mapped name differs from default). V1
SpanMetadata rules and snapshots would need updating. Deferred to a
follow-up PR.
- Manual set services (`"m"` source) and client stats payload — separate
PRs.

## Other details