Implement the top-of-list success notice on return

## Feature Description

Setting a feature up sometimes takes the user out of the hub altogether — into a Site Kit setup flow, or off to a Google service — and when they're finished the hub brings them back (#13338). Landing back on a list that looks much as it did before leaves them to work out for themselves whether what they went off to do actually worked.

This issue adds the confirmation they come back to: a success notice at the top of the list, on the tab they're returned to, telling them what they now have and where they can manage it. It's the same notice the hub already shows when a feature is set up without the user leaving the page (#13346), saying the same thing — in a second placement, because by the time the user is back the feature is set up and its card is gone from the list.

The notice belongs to the visit they returned in. Dismissing it, reloading, or coming back later leaves the hub in its ordinary state. And it's only shown when the feature really is set up, so a setup the user started and abandoned confirms nothing.

For reference, see the [Success detection & removal](https://docs.google.com/document/d/1sLWcimi6eZqbK4YXVCZtO0ZrfrDV7Ub218Hu_vpwmyI/edit?tab=t.0#heading=h.hnxlpo1aczw) and [Returning to the hub](https://docs.google.com/document/d/1sLWcimi6eZqbK4YXVCZtO0ZrfrDV7Ub218Hu_vpwmyI/edit?tab=t.0#heading=h.yl5go7548bwn) sections in the design doc, and the [success notice design](https://www.figma.com/design/7gBBIQhrIvLicLinAt9vta/Feature-Discovery-Hub?node-id=1214-31651) in Figma.

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

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

## Acceptance criteria

- When a user is returned to the hub having completed a setup that took them away from it, and that feature is now set up, a success notice is shown at the top of the list, above the feature cards, on the tab they're returned to.
- What it says comes from the feature itself (#13247) — a title, an optional second line, an optional call to action, and a dismiss labelled *"Got it"* unless the feature gives it another label — so a feature is confirmed in the same words wherever it's confirmed. For the newsletter sign-up form, for example: *"Success! Your Newsletter sign-up form by Reader Revenue Manager is set up"*, *"You can always update your sign-up form settings in Publisher center"*, and a **Go to Publisher center** button opening Publisher Center.
- It's the same notice as the one shown in a card's place (#13346), in a different position — not a second notice with its own appearance.
- It covers every feature a user leaves the hub to set up: the services activated through Site Kit's setup flow (#13338), those finishing on their own screens (#13340), the newsletter sign-up form (#13345), and Key Metrics (#13348).
- It's shown once, in the visit the user returned in. Dismissing it removes it; reloading the hub, or coming back to it later, shows neither the notice nor the feature.
- On **What's new?** it's shown in the notification area above the feature list that the auto-updates notice already uses (#13323), and the two share it: on return from a setup the success notice takes precedence, so it's the one shown. Once it's been dismissed, the auto-updates notice can take the area again.
- **All services and features** (#13328) gains the same notification area, in the same position above the feature list, holding one notice at a time. There the success notice is its only occupant — the auto-updates notice remains a **What's new?** notice.
- The notice matches the Figma design.

## Implementation Brief

- [ ] In `assets/js/googlesitekit/feature-discovery/pending-setup.ts` (#13338), carry the feature slug the last leg of the trip, alongside the tab:
- Change `getPendingSetupReturnURL( select, returnTab )` to `getPendingSetupReturnURL( select, { featureSlug, returnTab } )`, adding `notification: 'authentication_success'` and `slug: featureSlug` as query args on the built `getAdminURL( 'googlesitekit-features' )` URL (`addQueryArgs` from `@wordpress/url`), ahead of the existing `#/${ returnTab }` hash. This is the same `notification`/`slug` convention `useFinishSetup` already writes when it sends a module back to the dashboard — see the read side in e.g. `assets/js/modules/pagespeed-insights/notifications/index.js`.
- Update the one call site in `assets/js/components/setup/hooks/useFinishSetup.ts` (#13338) to pass `{ featureSlug: pendingSetup.featureSlug, returnTab: pendingSetup.returnTab }`.

- [ ] In `assets/js/googlesitekit/datastore/feature-discovery/constants.ts`, add `RETURNED_FEATURE_UI_KEY = 'feature-discovery-returned-feature'` — a `core/ui` key holding the slug of the feature the user has just returned from setting up, for this session only.

- [ ] In `assets/js/components/feature-discovery/FeatureDiscoveryApp.tsx`:
- Add a `useMount` hook that runs once on mount.
- Read `notification` and `slug` off `global.location.href` using `getQueryArg` from `@wordpress/url`.
- When `notification === 'authentication_success'` and `slug` is present: dispatch `setValue( RETURNED_FEATURE_UI_KEY, slug )` on `CORE_UI`, then strip both query args from the URL via `global.history.replaceState()`, preserving the hash fragment (`global.location.hash`).

- [ ] Create `assets/js/components/feature-discovery/FeatureDiscoverySetupSuccessNotification.tsx` — the registered notification for the shared top-of-tab slot:
- Props: `{ id, Notification }`
- Read `slug = useSelect( ( select ) => select( CORE_UI ).getValue( RETURNED_FEATURE_UI_KEY ) )`; return `null` if falsy.
- `onDismiss`: dispatch `select( CORE_UI ).setValue( RETURNED_FEATURE_UI_KEY, undefined )`.
- Render `` — reuse the in-place notice built in #13346 unchanged (same title/description/CTA/dismiss from the feature's `successNotice`), wrapped in the framework's `Notification` HOC for view tracking, modelled on `ModuleSetupSuccessNotification`.

- [ ] In `assets/js/googlesitekit/notifications/constants.js`:
- Add a `FEATURE_DISCOVERY_SETUP_SUCCESS_NOTIFICATION = 'feature-discovery-setup-success'` ID constant.
- If #13323 hasn't already, add `FEATURE_DISCOVERY_TOP: 'notification-area-feature-discovery-top'` to `NOTIFICATION_AREAS` — the slot the hub shares with the auto-updates notice.

- [ ] In `assets/js/googlesitekit/notifications/register-defaults.js`, register the new notification alongside `ENABLE_AUTO_UPDATES_BANNER_SLUG` and `'setup-success-notification-module'`:
- `Component: FeatureDiscoverySetupSuccessNotification`, `areaSlug: NOTIFICATION_AREAS.FEATURE_DISCOVERY_TOP`, `groupID: NOTIFICATION_GROUPS.SETUP_CTAS`, `priority: PRIORITY.SETUP_CTA_HIGH`, `viewContexts: [ VIEW_CONTEXT_FEATURE_DISCOVERY ]`.
- `checkRequirements`: resolve `slug = select( CORE_UI ).getValue( RETURNED_FEATURE_UI_KEY )`, returning `false` where it's unset; otherwise `await resolveSelect( CORE_MODULES ).getModules()` and return `true` only where `select( CORE_FEATURE_DISCOVERY ).getFeature( slug )` exists and `isFeatureConnected( slug ) === true` — the same "an abandoned setup confirms nothing" guard #13346 uses for its in-place notice.
- `groupID`/`priority` put this notice in the same competition as the hub's auto-updates registration (#13323, presumably `SETUP_CTA_LOW`): the lower `SETUP_CTA_HIGH` number wins the shared slot whenever both are queued, and once the success notice is dismissed, the auto-updates notice takes it.

- [ ] In `assets/js/components/feature-discovery/all-services/AllServicesTab.tsx` (#13328), mount `` above the goal groups, matching the mount `WhatsNewTab` already carries for the auto-updates notice (#13323). This tab has no other occupant for the slot, so the success notice is the only thing ever shown there.

### Test Coverage

- Extend `pending-setup.test.ts` (#13338) for `getPendingSetupReturnURL()`'s new `featureSlug` param: asserts the returned URL carries `notification=authentication_success` and `slug`.
- Extend `FeatureDiscoveryApp.test.tsx` to verify that on mount it captures `slug` into `core/ui` and strips `notification` and `slug` query args when both are present in the URL, and does nothing when either is missing.
- Add `FeatureDiscoverySetupSuccessNotification.test.tsx`: renders `FeatureSuccessNotice` for the captured slug, renders nothing without one, and dismissing clears the `core/ui` value.
- Extend `register-defaults.test.js`'s coverage for the new notification's `checkRequirements`: `true` only for a captured slug that maps to a connected, registered feature; `false` for no captured slug, an unregistered slug, or a not-yet-connected feature.
- Extend `AllServicesTab.test.tsx` (#13328) to confirm it mounts the shared notification area.

## QA Brief

-

## Changelog entry

-

Start with assets/js/googlesitekit/feature-discovery/pending-setup.ts and FeatureDiscoveryApp.tsx, then follow the notification registration in assets/js/googlesitekit/notifications/register-defaults.js and the mount in AllServicesTab.tsx. Use the named tests for the URL, mount, notification, registration, and tab behavior. Done means a returned, connected feature shows one dismissible success notice in the correct tab and session state is cleared afterward.

Written by the indexing model from the issue text.