fix(plugin-e2e): type window.grafanaBootData as @grafana/data's BootData

[unlikelyzero]

What this does

Types the global Window.grafanaBootData ambient augmentation in plugin-e2e as
import('@grafana/data').BootData instead of a hand-rolled inline subset.

Fixes: #2811

Why

The previous inline shape was a strict subset of Grafana core's real BootData type. When a
single tsc program merges this package's ambient Window declaration with Grafana's own
(e.g. Grafana core's tsconfig for typechecking e2e-playwright alongside app source), the
merged property types must be identical or TypeScript raises TS2717. Grafana core currently
masks this via skipLibCheck: true and works around the resulting file-order sensitivity with
an explicit include array ordering (see grafana/grafana e2e-playwright/tsconfig.json) — a
fragile mechanism, since which declaration silently wins depends on unspecified compiler
behavior.

Using Grafana's own BootData type directly removes the structural mismatch at the source, so
downstream consumers no longer need to work around merge order.

Changes

• packages/plugin-e2e/src/index.ts: grafanaBootData is now typed as
  import('@grafana/data').BootData.
• packages/plugin-e2e/package.json: adds @grafana/data as a dependencies entry (it was not
  previously a dependency of this package).

Verification

• npm run typecheck -w @grafana/plugin-e2e, npm run build -w @grafana/plugin-e2e,
  npm run lint -w @grafana/plugin-e2e, and npm run test -w @grafana/plugin-e2e all pass.
• Packed the built package and installed it as a local file: dependency in a grafana/grafana
  checkout. With the fix installed, reversing the include array order in
  e2e-playwright/tsconfig.json (which previously reproduced 3 TS2717-driven errors in
  packages/grafana-runtime/src/config.ts and
  packages/grafana-ui/src/components/DateTimePickers/WeekStartPicker.tsx) no longer reproduces
  those errors. With the normal include order, typecheck:e2e stays clean.

Note for reviewers

Raised the approach in #2811 first since this changes the package's public ambient type surface
and adds a new dependency (@grafana/data) that plugin-e2e did not previously have. Open to
an alternative shape if maintainers prefer not to take that dependency (e.g. dropping
grafanaBootData from the global augmentation entirely and keeping it as a package-local type).

[cla-assistant]

All committers have signed the CLA.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sunker]

Thanks for the detailed issue and for raising the PR.

I'd rather not take grafana/data on as a dependency just for this though, that's a permanent cost for every consumer to fix something narrow.

Looking closer at this, window.grafanaBootData augmentation in plugin-e2e is actually only needed internally by one fixture, it's not part of the real public API. So instead of widening it to match grafana/data's BootData, we can drop the global augmentation entirely and type it locally where it's used. That removes the conflict for anyone pulling in both types, not just grafana/grafana's e2e-playwright program, and needs no new dependency. Can you try this approach instead?