Expose entity_id in the Usage Analytics "Content" model (entity_id ↔ numeric id mapping)

**What problem will this feature request solve?**

The built-in **Usage Analytics → Content** model lists every piece of content with its numeric `id`, but not its stable `entity_id` — the portable identifier used by serialization and remote sync. Teams that adopt serialization or remote sync receive content keyed by `entity_id`, but most other surfaces (API URLs, embedding, deep links) are keyed by the instance-local numeric `id`. There is no first-class way inside Metabase to get the `entity_id → numeric id` crosswalk.

Today, building that mapping requires custom scripting against multiple API endpoints (`/api/collection/`, `/api/card`, `/api/collection/{id}/items`, etc.) and stitching the results together — and even then, cards embedded in dashboards or documents are only reachable through separate endpoints. Surfacing `entity_id` in the Usage Analytics Content model would make the mapping queryable directly, with no external tooling.

**Describe the solution you'd like.**

Add a `stable_entity_id` column (or change the current `entity_id` column to `id` and add `entity_id`) to the Usage Analytics **Content** model (and, where useful, the other Usage Analytics models that represent entity-bearing objects), so administrators can query the `entity_id ↔ numeric id` mapping for all content directly from a saved question or model — the same way they already query numeric IDs today.

**How does this feature request impact you?**

This is **blocking an Enterprise customer's production workflow.** They build an SDK-embedded experience that locates a piece of content and then scrolls to a specific card on a dashboard. Because `entity_id` is not available in the embedding/analytics surface, they must locate the card by its numeric `id`. To keep their `entity_id → id` mapping current they maintain custom API-scraping scripts, which is fragile and adds ongoing maintenance. Exposing `entity_id` in Usage Analytics would remove that scripting entirely and unblock the embedding workflow.

**Additional information**

* `entity_id` is already returned by the content APIs (e.g. `/api/collection/{id}/items`, `/api/card`), so the value exists on all content, but it is not surfaced in the Usage Analytics models.
* Related request metabase/metabase#73968 ("Return entity IDs from `/api/search`") would expose `entity_id` on another surface (search results); together these would cover both the analytics-query and the interactive-lookup paths.

Start by locating the Usage Analytics Content model and reviewing how the existing numeric id field is exposed. Compare its content sources with /api/collection/{id}/items and /api/card, then determine how entity_id should be named and included. Done means the entity_id-to-numeric-id mapping is queryable from a saved question or model, with coverage for the content represented there.

Written by the indexing model from the issue text.