Implement `in-place-panel` setup

Feature Description

Three of the features in the hub already have a place in Site Kit where they're set up: dashboard sharing has its dialog, email reports its subscription panel, and the PDF report its download panel. There's no Google service to connect and nowhere the user has to be sent — they simply need that panel in front of them.

So the hub opens the one Site Kit already has, over the hub itself. The user shares their dashboard, subscribes to email reports, or downloads a report, closes the panel, and is still on the hub where they were. The panel does its own saving and reports its own problems, exactly as it does everywhere else it appears; the hub's only part in it is opening the panel.

The PDF report is the odd one of the three: downloading a report is something you do, not something you turn on, so there's nothing for the hub to treat as "set up". Its card stays in the catalog for the user to come back to.

For reference, see the in-place-panel — configure in an existing modal or panel, on the hub section in the design doc.

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

Acceptance criteria

• Dashboard sharing is set up from its card's CTA (#13322), which opens Site Kit's existing dashboard sharing dialog over the hub, where the user shares their dashboard as they would from the dashboard itself.
• Email reports is set up from its card's CTA, which opens Site Kit's existing Email reports subscription panel over the hub, where the user subscribes as they would from the dashboard.
• The PDF report is run from its card's CTA, which opens Site Kit's existing Download your Site Kit report panel over the hub, where the user chooses what to include and downloads the report, seeing the same progress and messages the export shows elsewhere.
• Each of the three behaves exactly as it does elsewhere in Site Kit — the same content, the same saving, the same messages when something goes wrong. The hub adds no wording, no settings and no error handling of its own to them.
• Closing or cancelling any of the three leaves the user on the hub, on the tab they were on, with the feature not set up and its card as it was.
• Dashboard sharing counts as set up once any Google service has been shared with any role, and email reports once this user is subscribed; from that point the hub stops listing the feature.
• The PDF report is never counted as set up, because there's nothing to count: its card stays in All services and features (#13328) after a report is downloaded, though it still ages out of What's new? in the usual way.
• Each of the three is opened from the detail panel's CTA (#13330) exactly as from the card: the detail panel closes and the feature's own panel opens over the hub.
• The confirmation the user sees once one of these features is set up is covered by #13346.
• Everywhere else these three panels are opened from is unchanged.

Implementation Brief

• In assets/js/googlesitekit/feature-discovery/register-defaults.ts (or the final catalog registration module established by #13247):

  • Update the setup descriptors for the Dashboard sharing, Email reports, and PDF report features with FEATURE_SETUP_TYPES.IN_PLACE_PANEL and their existing catalog CTA labels.
  • Implement each descriptor's open( registry ) callback through CORE_UI setValue():
    • Dashboard sharing: set SETTINGS_DIALOG (dashboardSharingDialogOpen) to true.
    • Email reports: set USER_SETTINGS_SELECTION_PANEL_OPENED_KEY (emailReportingUserSettingsSelectionPanelOpened) to true.
    • PDF report: set PDF_DOWNLOAD_PANEL_OPENED_KEY (pdfDownloadPanelOpened) to true.
  • Define the completion state used by isFeatureConnected() for the two configurable features:
    • Dashboard sharing is connected when CORE_MODULES.getSharedModules() contains at least one shared module. Preserve an unresolved selector value while module data is loading.
    • Email reports is connected when the current user’s CORE_USER.getEmailReportingSettings() reports subscribed: true. Preserve an unresolved selector value while user settings are loading.
  • Do not provide an isEnabled completion predicate for PDF report, so that its card remains available in All services after an export as well.
  • Do not add a pending-setup record or navigation for these descriptors. They remain on the hub and are independent of the setup-flow return handling from #13338.

• In assets/js/components/feature-discovery/FeatureDiscoveryApp.tsx:

  • Mount DashboardSharingDialog and UserSettingsSelectionPanel alongside the hub shell so their existing core/ui state controls whether they render over the hub.
  • Mount both PDFSectionsSelectionPanel and PDFExportRoot for the PDF feature when pdfGeneration feature flag is enabled.
  • Keep the existing detail panel and tab content in the same app tree. Starting an in-place setup from a card or detail-panel CTA must close the detail panel before the selected surface opens, using the shared setupFeature()/FeatureCTA flow from #13322 and #13330.
  • Use the feature-discovery view context already supplied by the hub root when mounting these components, allowing their existing tracking and permission behavior to remain consistent with their other entry points.

Test Coverage

• Extend feature-discovery datastore tests to verify the three in-place descriptors open the expected CORE_UI key and value through setupFeature().
• Add tests for the Dashboard sharing and Email reports completion predicates, including loading/undefined selector values and their connected states.
• Add FeatureDiscoveryApp tests with the existing surfaces mocked to confirm all required components are mounted and that their UI keys control the opened state.
• Extend the relevant FeatureCTA and detail-panel tests to verify card and detail-panel setup use the same in-place action, close the detail panel, and do not navigate away.

QA Brief

Changelog entry