apply: support pruning assets removed from source (GitOps delete reconciliation)

[mmanciop]

Problem

dash0 apply has create-or-update (upsert) semantics but never deletes. Unlike Terraform, the CLI keeps no state, so when an asset definition is removed from the source repository there is no supported way for the CLI to remove the corresponding asset from Dash0. Teams adopting the CLI for GitOps / CI-CD must currently fall back to manual deletes or ad-hoc git-log parsing to reconcile deletions.

Why it matters

GitOps workflows expect the source repository to be the single source of truth: removing a definition should converge the backend by deleting the asset. Without this, deleted definitions leave orphaned assets in Dash0. This lifecycle gap is a primary reason teams stay tied to Terraform even when they prefer the CLI's simplicity for everything else.

Expected user-facing behavior

An opt-in reconciliation / prune capability (for example dash0 apply --prune or a dash0 sync command) that, given a set of desired definitions and a way to identify CLI/pipeline-managed assets, deletes managed assets that exist in Dash0 but are absent from the desired set.

Key requirements:

• Opt-in and safe by default — it must never delete assets it does not manage (e.g. UI-created assets).
• A reliable "managed by this source" scoping mechanism. Note that for check rules, dashboards, and views the CLI strips dash0.com/origin on write, so origin cannot currently serve as that marker for those types — the design must specify how managed assets are identified.
• A --dry-run mode that previews deletions without performing them.
• Coverage across the asset types that apply already supports.

Acceptance criteria

• A documented, opt-in way to delete assets that were removed from the source set.
• Pruning is scoped to managed assets and cannot delete unmanaged assets.
• --dry-run lists what would be deleted without deleting it.
• Documented for CI/CD use, with the scoping / marker convention spelled out.