[Datadog] Default --field-profile otel is a poor fit for Datadog-Agent-origin dashboards

## Context
Verified during a live migration review (real "Kubernetes - Overview" DD dashboard against an OTel `metrics-*` cluster).

`datadog-migrate` defaults to `--field-profile otel`. But `otel` ships a rich **tag** baseline and **zero** metric-name overrides, so metric names are only dot-to-underscore flattened (`kubernetes.cpu.usage.total` -> `kubernetes_cpu_usage_total`). That matches neither:
- an OTel-native index (which stores dotted semconv names like `k8s.pod.cpu.usage`), nor
- the Datadog-Agent-origin reality, where Elastic Agent / Metricbeat naming is the more natural target.

Net: the default produces placeholder metric fields that frequently do not exist in the real target, so an offline run can look "migrated" while most panels would be empty.

## Ask
Reconsider the default (or the first-run guidance) so DD-Agent-origin operators are steered toward `elastic_agent` + `--metric-map-file`, and/or surface a clear "you probably need to pick/confirm a profile" prompt. No silent behavior change without a decision.

## Acceptance
- A documented, defensible default (or explicit no-default prompt) for `datadog-migrate`.
- First-run output makes the profile choice and its consequences obvious.
- Docs updated (`docs/sources/datadog.md`, `docs/command-contract.md`).

Found via the schema-translation walkthrough; docs clarifications for the tag-vs-metric confusion already landed in `docs/sources/datadog.md`.

Start with the current datadog-migrate profile behavior and the schema-translation walkthrough, then read docs/sources/datadog.md and docs/command-contract.md. Clarify whether the project will document a defensible default or require an explicit profile choice, and make the first-run consequences clear. Validate the resulting guidance against Datadog-Agent-origin and OTel scenarios.

Written by the indexing model from the issue text.