Implement setup for the Key Metrics feature

## Feature Description

Key Metrics is the hub's card for the metrics at the top of the Site Kit dashboard. It isn't a Google service: there's nothing to connect, and it's Analytics that supplies the data behind them — which is why the card is only offered to users who have Analytics connected.

Its call to action takes the user to Site Kit's user input questionnaire, whose first question — what the site is for — determines the set of metrics. The questionnaire today always finishes on the dashboard; a user who came from the hub should come back to it instead.

Setting up from the hub is one of several ways a site can come to have key metrics, so what the card goes by is whether the site has them, not how they were chosen.

A later release replaces the trip out to the questionnaire with a panel on the hub itself. This issue is the first version of it.

For reference, see the [Key Metrics — the site-purpose questionnaire](https://docs.google.com/document/d/1sLWcimi6eZqbK4YXVCZtO0ZrfrDV7Ub218Hu_vpwmyI/edit?tab=t.0#heading=h.i7rj4af5pab1) section in the design doc.

---------------

_Do not alter or remove anything below. The following sections will be managed by moderators only._

## Acceptance criteria

- Key Metrics is set up from its card's CTA (#13322), which takes the user to Site Kit's existing user input questionnaire, whose first question — what the site is for — determines the site's metric selection.
- Completing the questionnaire returns the user to the hub, on the tab they started from (#13338), rather than to the dashboard it goes to today.
- Where the questionnaire wasn't reached from the hub, it completes exactly where it does today.
- Leaving the questionnaire unanswered changes nothing: the feature isn't set up, and its card is still there when the user returns to the hub.
- The feature counts as set up once the site has its key metrics, however they were chosen — from the hub, or anywhere else in Site Kit that sets them up — and from that point the hub stops listing its card.
- The card is offered only to users who have Analytics connected (#13247), so its CTA always has somewhere to go.
- Key Metrics is set up from the detail panel's CTA (#13330) exactly as from the card.
- The confirmation the user sees on returning to the hub is covered by #13356.

## Implementation Brief

- [ ] In `assets/js/modules/analytics-4/feature-discovery/`, create `constants.ts`:
- Export `KEY_METRICS_FEATURE_SLUG = 'key-metrics'`.
- [ ] In `assets/js/modules/analytics-4/feature-discovery/index.ts`:
- Import `CORE_SITE` from `@/js/googlesitekit/datastore/site/constants` and `KEY_METRICS_FEATURE_SLUG` from `./constants`.
- Update the existing `registerFeature( 'key-metrics', { … } )` call to register under `KEY_METRICS_FEATURE_SLUG`.
- Extend that entry's `setup` descriptor with following:
- `getSetupURL: ( select ) => select( CORE_SITE ).getAdminURL( 'googlesitekit-user-input' )` — the destination the shared `setup-flow` handling in `setupFeature()` (`assets/js/googlesitekit/datastore/feature-discovery/features.ts`, built by #13338) navigates to for any feature with no `moduleSlug`.
- `isEnabled: ( select ) => select( CORE_SITE ).isKeyMetricsSetupCompleted()` — Key Metrics has no module of its own, so this overrides the default module-connected check; `isFeatureConnected()` (`assets/js/googlesitekit/datastore/feature-discovery/selectors.ts`) already reads `setup.isEnabled` first when present.
- The entry's `prerequisiteModules: [ 'analytics-4' ]` is already set.
- [ ] In `assets/js/components/user-input/UserInputQuestionnaire.js`:
- Import `useRegistry` from `googlesitekit-data`.
- Import `consumePendingSetup` and `getPendingSetupReturnURL` from `pending-setup` (landed in #13338), and `KEY_METRICS_FEATURE_SLUG` from `@/js/modules/analytics-4/feature-discovery/constants`.
- Call `const registry = useRegistry();` alongside the component's other hooks.
- In `submitChanges()`, once `saveUserInputSettings()` resolves without `response.error`, before the existing `navigateTo()` call:
- Call `await consumePendingSetup();`.
- Check if pending setup's slug is key metrics feature slug by comparing it with the constant `KEY_METRICS_FEATURE_SLUG`. If it is equal, call `getPendingSetupReturnURL`, else `dashboardURL`. Collect the result in `url`.
- Call `navigateTo` with `new URL` and pass the above collected result in it.
- Add `registry` to `submitChanges`'s `useCallback` dependency array.

### Test Coverage

- Create `assets/js/components/user-input/UserInputQuestionnaire.test.js` covering `submitChanges()`'s completion routing: navigates to `getPendingSetupReturnURL()`'s URL when a `key-metrics` pending-setup record is present, and falls back to the dashboard URL when there's no record, an expired one, or one belonging to a different feature slug.
- Extend `assets/js/modules/analytics-4/feature-discovery/index.test.ts` (create if it doesn't already exist) to assert the `key-metrics` entry's `setup.getSetupURL()` resolves to the `googlesitekit-user-input` admin URL and `setup.isEnabled()` reflects `core/site`'s `isKeyMetricsSetupCompleted()`.

## QA Brief

-

## Changelog entry

-

Start with assets/js/modules/analytics-4/feature-discovery/index.ts and the pending-setup handling referenced in assets/js/googlesitekit/datastore/feature-discovery/features.ts, then inspect UserInputQuestionnaire.js. Run or extend the specified feature-discovery and questionnaire tests. Done means the key-metrics setup URL and enabled state resolve correctly, questionnaire completion returns to the hub only for the matching pending setup, and existing dashboard routing is unchanged otherwise.

Written by the indexing model from the issue text.