Document Grafana dashboard export format requirements for file-based migration

[miguel-sanchez-elastic]

Summary

--input-mode files dashboard migration only understands one shape of Grafana dashboard export, but the Grafana UI's Export dialog offers several. Nothing in our docs tells operators which one to pick, so it's easy to export the wrong thing and get a confusing failure with no obvious cause.

Current behavior (verified)

• extract_dashboards_from_files() only globs *.json and only recognizes a document with a top-level panels/rows key (or the {"dashboard": {...}} API wrapper).
• Grafana's newer V1 resource and V2 resource export models wrap the dashboard body under apiVersion/kind/metadata/spec instead. The extractor doesn't unwrap spec, so these exports — JSON or YAML — are silently skipped, surfacing only as no Grafana dashboards found ... expected top-level 'panels' or 'rows' key.
• The default export (no need to open Advanced options) already produces the working shape: Classic model, JSON format.
• The "Share dashboard with another instance" / "Export for sharing externally" toggles were verified to have no effect on migration output (tested by exporting the same dashboard both ways and diffing the result) — they only swap datasource uid/name for a placeholder in report metadata.

Proposal

• Add a short "File Export Scope" note to docs/sources/grafana.md, alongside the existing "Live Extraction Scope" section, stating: use the default export (Model = Classic), no need to open Advanced options; V1/V2 resource and YAML aren't supported; the sharing toggles don't matter.

Non-goals

• Adding support for V1/V2 resource unwrapping or YAML ingestion (separate follow-up if desired).

Related

• observability_migration/adapters/source/grafana/extract.py (extract_dashboards_from_files)
• docs/sources/grafana.md § Live Extraction Scope

[Shaurya2k06]

Hey, could I take this up?
cc @miguel-sanchez-elastic

[Shaurya2k06]

Let me know if #297 is a good solution to the above issue!
cc @miguel-sanchez-elastic