Improve error response when calling project tags-values endpoint with a context-backed property

### Problem Statement

When a customer calls `GET /api/0/projects/{org}/{project}/tags/{key}/values/` with a key that's a documented searchable property but is stored as a Snuba context column rather than a promoted tag (e.g. `device.name`), the endpoint returns a generic 404 with `{"detail": "The requested resource does not exist"}`. This gives no signal that the property is queryable through the organization-scoped equivalent. Customers (and AI documentation tools) reasonably interpret the 404 as "this property doesn't exist," when in fact the right move is `GET /api/0/organizations/{org}/tags/{key}/values/?project={project_id}`.

### Solution Brainstorm

Either (a) keep the 404 but include a more specific `detail` when the key resolves to a known Snuba column (e.g. `"device.name is stored as event context, not as a tag. Use the organization-scoped /tags/{key}/values/ endpoint."`), or (b) document the behavior on the API reference page. Option (a) is more discoverable; option (b) is a docs-only fix and arguably belongs in `sentry-docs` instead.

### Product Area

APIs

Start by tracing GET /api/0/projects/{org}/{project}/tags/{key}/values/ and compare it with GET /api/0/organizations/{org}/tags/{key}/values/?project={project_id}, focusing on how a key resolves to a Snuba context column. The issue is done when callers receive a discoverable response for context-backed properties or the API reference documents the organization-scoped alternative.

Written by the indexing model from the issue text.