<!-- Provide a general summary of your changes in the Title above -->

## Description

<!-- Describe your changes in detail -->

- Rename the route metadata key to listen_path to accurately describe
what it returns (the API's static listen path, not an HTTP route
template)
- Add a new endpoint metadata dimension that surfaces the tracked
endpoint path from TrackEndpointMiddleware, giving per-endpoint
granularity in OTel metrics
- Decouple TrackEndpointMiddleware from EnableAnalytics so endpoint
tracking works in OTel-only deployments

The route dimension returned the same static listen path (e.g. /api/v1/)
for every request to an API — users couldn't distinguish /users/{id}
from /orders/{id} in metrics. The name route was also misleading per
OTel http.route semantic conventions.

Both Classic and OAS APIs support trackEndpoint configuration, but the
tracked path was never exposed to OTel metrics. Additionally, the
middleware was gated behind EnableAnalytics, blocking OTel-only
deployments from using it.

  Configuration example

```
  TYK_GW_OPENTELEMETRY_METRICS_APIMETRICS='[{
    "name": "api.requests.by.endpoint",
    "type": "counter",
    "dimensions": [
      {"source": "metadata", "key": "api_id", "label": "tyk.api.id"},
      {"source": "metadata", "key": "listen_path", "label": "tyk.listen_path"},
      {"source": "metadata", "key": "endpoint", "label": "tyk.endpoint", "default": "unmatched"}
    ]
  }]'
```

With track_endpoints configured for /status/{id} and /get:

```api_requests_by_endpoint_total{tyk_api_id="9", tyk_listen_path="/tracked/", tyk_endpoint="/status/{id}" } 15```
 ```api_requests_by_endpoint_total{tyk_api_id="9", tyk_listen_path="/tracked/", tyk_endpoint="/get"} 8```

Without track_endpoints, the endpoint dimension is empty (cardinality safe - no raw paths):
```api_requests_by_endpoint_total{tyk_api_id="3",
tyk_listen_path="/test/", tyk_endpoint=""} 20```
  
  
## Related Issue

<!-- This project only accepts pull requests related to open issues. -->
<!-- If suggesting a new feature or change, please discuss it in an
issue first. -->
<!-- If fixing a bug, there should be an issue describing it with steps
to reproduce. -->
<!-- OSS: Please link to the issue here. Tyk: please create/link the
JIRA ticket. -->
https://tyktech.atlassian.net/browse/TT-16561


## Motivation and Context

<!-- Why is this change required? What problem does it solve? -->

## How This Has Been Tested

<!-- Please describe in detail how you tested your changes -->
<!-- Include details of your testing environment, and the tests -->
<!-- you ran to see how your change affects other areas of the code,
etc. -->
<!-- This information is helpful for reviewers and QA. -->

## Screenshots (if appropriate)

## Types of changes

<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Refactoring or add test (improvements in base code or adds test
coverage to functionality)

## Checklist

<!-- Go over all the following points, and put an `x` in all the boxes
that apply -->
<!-- If there are no documentation updates required, mark the item as
checked. -->
<!-- Raise up any additional concerns not covered by the checklist. -->

- [ ] I ensured that the documentation is up to date
- [ ] I explained why this PR updates go.mod in detail with reasoning
why it's required
- [ ] I would like a code coverage CI quality gate exception and have
explained why




<!---TykTechnologies/jira-linter starts here-->

### Ticket Details

<details>
<summary>
<a href="https://tyktech.atlassian.net/browse/TT-16561" title="TT-16561"
target="_blank">TT-16561</a>
</summary>

|         |    |
|---------|----|
| Status  | Open |
| Summary | Add endpoint-level metrics via OpenTelemetry |

Generated at: 2026-03-20 16:55:54

</details>

<!---TykTechnologies/jira-linter ends here-->